In this conversation, Stephan Livera and Jonas Nick discuss the implications of quantum computing on Bitcoin’s security, focusing on the risks posed to cryptographic signatures. They explore the current vulnerabilities in Bitcoin, the potential for quantum attacks, and the need for post-quantum cryptographic solutions. The discussion covers various signature schemes, including hash-based signatures, their trade-offs, and the challenges of transitioning to a quantum-resistant Bitcoin. They also touch on the implications for hardware wallets, multi-signature schemes, and the potential need for block size increases to accommodate new signature sizes.
Takeaways:
🔸Quantum computers pose a real risk to Bitcoin’s cryptography.
🔸Current Bitcoin signatures are vulnerable to long-range attacks.
🔸Hash-based signatures are significantly larger than current signatures.
🔸Transitioning to quantum resistance will require careful planning.
🔸The Bitcoin community must reach a consensus on new schemes.
🔸Verification costs will increase with new signature schemes.
🔸Hardware wallets will need to adapt to new signature requirements.
🔸Block size discussions may need to be revisited in light of quantum risks.
🔸The timeline for quantum computing advancements is uncertain.
🔸A gradual transition to quantum resistance may be necessary.
Timestamps:
(00:00) – Intro
(01:49) – How real is quantum risk to Bitcoin?
(04:39) – When could quantum pose a threat to Bitcoin’s cryptography?
(09:56) – Long range vs Short range attacks
(12:37) – How many coins are vulnerable to Long range attacks?
(14:12) – Different types of cryptography and exploring Hash-based signature schemes
(17:00) – Categories of Hash-based signature scheme and their pros & cons
(23:42) – How do Hash-based signatures work?
(32:14) – Would Lightning, Multi-sig, Taproot, Silent Payments, Atomic swaps work in a post-quantum world?
(38:50) – What are Adaptor signatures & how do they affect atomic swapping?
(41:27) – Will we need new Bitcoin hardware wallets?; Signature production & verification
(44:41) – Signature size and Bitcoin block capacity implications
(46:52) – Should we revisit the block size conversation?
(54:57) – Overview of SPHINCS+ & SHRINCS
(59:49) – Transitioning to post-quantum signature schemes; Overview of BIP 360
(1:09:06) – Closing thoughts
Links:
Stephan Livera links:
- Follow me on X: @stephanlivera
- Subscribe to the podcast
- Subscribe to Substack
Transcript:
Stephan Livera (00:01)
Hi everyone and welcome back to Stephan Livera podcast. Today we’re going to be discussing a hot topic in Bitcoin circles today, which is quantum and ⁓ what are the risks to it, you know, and of course, Jonas’s ⁓ work on this. Now, long time listeners, you’ll know who Jonas Nick is, but for new people, Jonas is working as part of the team. He is a cryptographer ⁓ and Bitcoin researcher and developer. He’s part of the team at Blockstream Research. He’s been writing papers and we’re to be discussing one in particular today.
but I guess we’ll talk a bit more broadly about it. I guess also of notes for listeners, Jonas is also a maintainer of Libsac P256k1. So he’s a maintainer of one of the, let’s say a key library that relates to the cryptography that we already use in Bitcoin today. So just for listeners who are unaware. So Jonas, first off, welcome back to the show.
Jonas (00:54)
Hello everyone, happy to be here.
Stephan Livera (00:56)
So ⁓ let’s just start with a bit of your thoughts on, you your thoughts as a cryptographer working in Bitcoin. How real is this risk? Like, I guess people want to get a sense of that because there’s been a lot of talk recently about new advancements in the field of quantum computing and what does it mean for us. So can you give us just a bit of a broad overview there on your thoughts?
Jonas (01:09)
Mmm.
Right, right. So from my perspective, ⁓ what we’re doing in Bitcoin, right, we have these coins and we authorize coins using digital signatures. And those digital signatures, we believe them to be secure and we even have security proofs that show that they are secure.
And if you ever look into one of those cryptographic papers, maybe one day, and then you see, okay, there are these security theorems that precisely define what security means in that context, right? Now in Bitcoin, we use ECDSA or Schnorr signatures. And when we look into security theorems for those signature schemes, when they spell out exactly what the requirements are, they essentially say, this scheme is secure as long as our elliptic
that we depend on in Bitcoin is secure. The curve that we use in Bitcoin was chosen by Satoshi, it’s called SecP256k1. Now, from my perspective, when I write security proofs like this and I write a theorem like this, then I write down this requirement and then I think to myself,
The problem here is that we know that this elliptic curve is not secure. This has been known since the mid 90s after the invention of Schor’s algorithm that would show you how to break the security of such a curve. The only thing that is missing would be this ⁓ machine that is called a quantum computer.
and that adds a little bit of unease when I write these kinds of papers.
The question is, is it realistic whether a quantum computer appears or not? And in my opinion, it’s very important that we think about this problem, how to secure Bitcoin against quantum computer, because we want Bitcoin to be secure against very, very powerful adversaries. And we don’t just want Bitcoin to be secure if some random person on Twitter turns out to be right and quantum computers don’t turn out to become a thing in
in the future. And this is what is motivating me to work on this problem.
Stephan Livera (03:40)
Yeah. And so do you have any thought or research or anything you’ve looked at in terms of timelines or you don’t have any idea on what is realistic ⁓ for a quantum computer that could break Bitcoin’s cryptography?
Jonas (03:57)
The problem is that there doesn’t seem to be a consensus on a timeline and it seems to be very hard to predict these kinds of things. I I am not losing sleep over it right now. I’m thinking more in a decade long timeline or something like that. Not as much in a three to four year timeline where Bitcoin would really be affected. also we still need to, assuming a quantum computer would appear in 10 years.
Then we still need time in between to migrate and as we know in Bitcoin, Bitcoin moves kind of slow. We need to prepare soft forks. We need to ⁓ Deploy those soft forks and do the do so securely and all that takes ⁓ time time to
Stephan Livera (04:51)
I see. And so from what I’ve seen, see the gamut of, there are people who think, it’s coming in a few years. And there are other like legitimate quantum computing experts who think it’s like 20 years away. And then there’s maybe some people who think it’s just never happening, right? So I guess that’s sort of the range of what you’re seeing some people saying.
Jonas (05:04)
Hmm.
Yep.
Yep.
There are some really
bad arguments, think. The worst one that I see from like pretty regularly is if a quantum computer appears, then the entire banking system breaks down and we have much bigger problems. And I think this doesn’t make sense. First of all, it’s a non sequitur. It doesn’t mean that we shouldn’t secure Bitcoin. And also it’s just the fact that the world is migrating to post quantum schemes, whether you see it or not. mean, there are governments
bodies that mandate the use of post-quantum schemes and ⁓ if I use my SSH tool for non-techies, that’s the tool you use to log into computers over a network, it will try to use a post-quantum scheme and if the server doesn’t support it because it has an old version, then it will print this giant version insecure, you’re now using a non-quantum secure channel and similarly my current
just using standard Firefox. It also supports post quantum secure communication channels via TLS and if the server supports it, it will use it. So we’re already using post quantum signature schemes and the world is moving towards it.
Stephan Livera (06:29)
I Now, and I’m with you there, and I think it’s ⁓ perhaps also important to understand that it’s easier to upgrade a centralized system like a banking system than it is to upgrade a decentralized system like Bitcoin. So that’s something we also need to take into account. ⁓ But I think perhaps what we have seen is some people who just think, hey, cut the devs, just do something, just do it now kind of thing. But it’s like, no, there’s also actually trade offs that would be required for us to actually do that. And we might have to
Jonas (06:39)
Right.
Stephan Livera (06:57)
pay a cost in some way. So I think that’s important.
Jonas (07:00)
Right.
There’s
a very important point. I see this also all the time. Why haven’t you done anything already? The problem really is that there’s no alternative in the post-quantum space that we could just use. ⁓ Any post-quantum scheme that we will use will have some effects that will be visible to the users. They have downsides. There’s a huge design space on possible upsides and downsides, pros and cons that we can pick, but there’s no
Stephan Livera (07:15)
for free per se, right?
Jonas (07:30)
scheme that we could just ⁓ take that has exactly the same properties as the cryptographic schemes that we use right now.
Stephan Livera (07:38)
Gotcha. Okay, so I’m going to do my best to try and offer a simple explanation of what we do today in Bitcoin and you tell me if I’m getting anything wrong, but I’m going to try to offer that just for listeners who are, let’s say new and trying to understand what’s going on here. in Bitcoin today, maybe you can think of it like our private key is this massive, massive number. And in practice, when we go to spend Bitcoin, really what we’re doing is we’re kind of showing our public key and we’re doing
like a multiplication, we’re signing a transaction and we’re showing the public key and the signature. And I guess the point is in classical computing world, I guess you’re saying it’s like, would take like billions of billions of years to kind of reverse out that private key from the signature that we post on chain. But in the hypothetical quantum world with the use of Shor’s algorithm,
quantum attacker or once the so-called Q day happens, that attacker would be theoretically able to reverse out your private key from what we’re posting on chain now. Is that kind of a loosely fair summary of what’s happening?
Jonas (08:50)
I think that’s a pretty fair summary. I it still depends on what kind of quantum computers we’ll see, how long the quantum computer will take to actually ⁓ break this. And I think another interesting, yeah.
Stephan Livera (09:01)
Got it. And that’s probably a good point to explain the short range attacks
and the long range attacks. So the idea is if you have ever exposed your public key and there are certain output types that have their public key exposed, they are vulnerable to what’s called a long range attack. Like right now today, anyone can just download the chain and the hypothetical quantum computer in the future could reverse out the private key for that. And then the short range attack is when
So let’s say we broadcast our transaction and it goes into the mempool ⁓ and only in that short period of time when it’s let’s say in the mempools before it gets confirmed into a block that hypothetically the quantum attacker could like see your public key and the signature and try to reverse it out and steal it. But that’s why it’s a much higher bar for them to execute a short range attack versus just doing a long range attack.
Jonas (09:55)
Yes.
Yes, that is right. And I think another interesting aspect that you mentioned is that we know in the classical computing world that it would take billion years to reverse a public key or to break a public key. And that is not really true. That is just an assumption that we make. So far, we don’t know an efficient algorithm that would be able to break our elliptic curve. But we don’t know whether one exists or not. It is just that
⁓ no one has found such an algorithm so far and I think that
Stephan Livera (10:31)
Right, that can bring it to like
a realistic time. I was researching a little bit, it’s called Pollard’s Row, but apparently it brings it from like 2 to the 256 down to like 2 to the 128, so it’s like still like just basically impossible. But in the quantum world, as I’m reading, they’re saying this idea is that the quantum computer would sort of bring it to, quote unquote, a polynomial time thing instead of being an exponential time thing. that basically, in computer science speak, as I’m reading, means
Jonas (10:37)
Yep.
Yes. Yes.
Yes.
Stephan Livera (11:00)
It’s now in the realm of possibility, instead of like basically very very impossible or very very very unlikely.
Jonas (11:01)
Yes, that is correct.
But I was trying to say that another angle for this type of research
is not just what do we do in case a quantum computer appears, it’s also what do we do in case our curve is broken in the classical way. I think there’s a low likelihood of that. Some people think there’s a higher likelihood of that than a quantum computer actually appearing, but there’s just this other angle at looking at this. What if the assumptions we use in Bitcoin just break down even in the classical world, what can we do?
Stephan Livera (11:20)
Okay.
I see. So yeah, as you said, as I understand then that it’s possible that there can be classical breaks also. And then I guess another context setting thing here is the estimate of coins currently vulnerable to what we said as long range attacks. I think the last number I’ve seen people talk about is something like five or six million coins. Now, okay, one million is rumored to be, know, Satoshi, maybe Satoshi is dead, who knows, but there’s a lot of address reuse and instances where the coins have
Jonas (11:56)
Mm-hmm.
Stephan Livera (12:06)
already had their public key exposed. And so that’s also just worth understanding that there are a lot of coins already vulnerable today. Although maybe in the future, like if it started to be a real thing, then we would start to see people like move and migrate out. ⁓ But what we’re talking about then is that if a lot of people at least went into hashed address types, then
They are now only vulnerable to the short range attack, not the long range attack.
Jonas (12:37)
Yep. Yeah. Yeah, that is right. I mean, this is kind of touches upon one of the big questions, which is what to do with the coins that have not migrated to a post quantum scheme. And fortunately, that’s not a question that cryptography has an answer to.
Stephan Livera (12:57)
⁓ Right. ⁓ And so I guess as this paper gets at is hash-based signature schemes for Bitcoin. So can you just set a bit of the context for us? What are the different categories here? So I presume, you what we have now is an elliptic curve based scheme. That’s what we’re using now, ECDSA or Schnorr. There’s hash-based and there’s some other types. Can you just explain a bit about that?
Jonas (13:22)
Right, so I mentioned earlier that the security of the signature schemes we use today, they depend on assumption, assumption that is that the curve is not broken, and we can design cryptography also on different assumptions. And…
The kind of assumptions we’re looking at are assumptions that we believe to be hard still in a post-quantum world. And ⁓ one of those assumptions is that ⁓ hashes are still secure against quantum computers, that they are still collision resistant, perhaps more easily, let’s say you have a hash function. Maybe you know hash function gets some input and produces some output, the hash. And the hash is supposed to be some
completely independent thing from the input such that when you see the output you cannot really you cannot recompute the input except by just trying out all possible inputs the quantum computer gets a little bit better at that
but not in the sense that the attack would become polynomial as you mentioned before. So still not in the realm of actual ⁓ physical possibilities. So hashes are one of the assumptions that we can look at and the other big type of assumptions would be based on so-called lattices and that’s something we haven’t. Some people have looked at it in the Bitcoin space and there exist ⁓ standardized schemes for lattices ⁓
But in our work so far we have looked into hash based signatures. Mainly for the reason that they are the most obvious ⁓ candidate because the assumption that hashes are secure is an assumption that is already in place in Bitcoin. We use hashes to identify transactions, we use hashes to identify blocks. So if hash functions weren’t secure, we arguably would have a
bigger problem than just just signatures being insecure but rather we wouldn’t even know what the best blockchain is and we wouldn’t have we would have chain splits and so on so that would be potentially even worse and this the this assumption is relatively conservative and also
All the other signature schemes in the post-quantum world, at least the realistic ones, they also make use of hash functions. So if hash functions are broken, all of them are broken. But hash-based signatures also come with downsides, for sure.
Stephan Livera (16:00)
Got it. ⁓ And so these are some of the, yeah, so do you wanna start walking us through some of the ⁓ points you explore in this paper around hash-based schemes? Like what are some of the categories of scheme and what are some of the upsides and the downsides of them?
Jonas (16:23)
Right, so first I should mention that these hash-based or post-quantum signature schemes, they sort of exist and they have been standardized by National Institute Standards and Technology, I think, US ⁓ thing. ⁓ They exist, they are implemented, as I said, for example, in Firefox and in my SSH.
but they have not been designed for the Bitcoin application. They have been designed for signing certificates in the web and for signing software ⁓ releases. In the Bitcoin space we have a little bit different requirements and this is why we looked at how can we ⁓
perhaps modify these standardized schemes that exist a little bit to make them better suited for ⁓ the Bitcoin use case. This was one of the main questions we started out with when writing this paper.
Stephan Livera (17:23)
Yeah, and so I guess in simple terms, the main downsides as I’m reading and trying to understand, it’s, I mean, there’s a few things, ⁓ but it is about kind of the size of that transaction and the computational requirement. And then I guess this comp, this aspect of whether it’s a stateful design or a stateless design, because that also has some other trade offs for us in Bitcoin. So can you…
Maybe give us like a rough sketch of that. Like what would the trade off space look like? Are we talking like much, much larger transaction sizes? Give us, give us some sense of that.
Jonas (18:00)
Yeah, so.
Our current Schnorr signatures are 64 bytes and ECDSA signatures are about 70 bytes. Now if we would just use the standardized signature scheme hash-based it would be 8,000 bytes. So that is a couple of like it’s I believe it’s about 10, 12, 13 transactions like average transactions on the network just with single signatures.
Stephan Livera (18:21)
Like a hundred X or more than a hundred X.
Jonas (18:32)
sure. ⁓
And well, the effect of that is that fewer transactions fit into a block. Fewer people can make transactions. ⁓ Potentially fees would go up quite significantly. Or we would need to discuss a potential block size increase to support the same number of transactions as before. That’s kind of the obvious downside that hash-based ⁓ signatures have. And this is already, there are multiple versions of this standardized scheme.
It’s called SLH ⁓ DSA by the way, stateless hash based digital signature algorithm I believe. And ⁓ there are two versions of this. One is called the fast version, which is fast for signing and verification. And the other one is called small version and 8,000 bytes is already the small version. And we looked at, ⁓ okay, can we somehow reduce the size of a hash based signature scheme?
And one of the main things we looked at, mean we weren’t the first to think about this, but one of the characteristics in Bitcoin is that
We usually want to avoid reusing addresses. So we generate an address and that encodes our public key. We give it to the sender. Sender sends to this address and then for the next sender, we try to generate a new address and we do that for privacy reasons to make it more difficult to link transactions on the chain.
⁓ So the average number of signatures we produce for a single public key on Bitcoin, least usual in the usual cases, is about one, between one and two. Sometimes you will need to use, ⁓ you sign a transaction and then it doesn’t confirm, so you need to ⁓ increase the fee, sign again.
Stephan Livera (20:29)
to resign or there may be cases
where you want to like prove ownership of an address, that kind of thing.
Jonas (20:34)
Right,
yeah, that’s a good point. Or maybe you’re using lightning-like payment channels where you sign a transaction very often. So there are cases where we sign more often, but I would say in the general case, we sign rarely. Now these hash-based signatures, we can reduce them significantly.
by putting ⁓ a limit on the number of times you can sign with a single public key. So we can say, with this public key, you can sign 16 billion times. If you sign more than 16 billion times, an ⁓ attacker will be able to potentially, or will be able with relatively little effort to ⁓ forge a signature and steal your coin.
be below that limit. Now the question is for regular users do they ever need more than 16 billion signatures for a single public key? If we buy that assumption then we can reduce the size from 8,000 bytes to 3,000 bytes, 4,000 bytes in that range.
So that is one of the things where we applied this specific Bitcoin domain to the question of… ⁓
how to optimize these signature schemes. I think the other big thing that we did is we looked at, so research in a post-quantum space is not standing still. So they are ⁓ new optimizations even for those hash-based schemes. And we also ⁓ looked at them and we… ⁓
We experimented with them and implemented them and then looked at how much improvement we would get. So this gets us another 10, 20%, sometimes in terms of size compared to the already standardized hash based signatures.
Stephan Livera (22:39)
I see. And just to be clear, what you’re talking about there with the 8,000 bytes, that’s Sphinx Plus, And then this other type I’ve seen called Shrinks. Can you talk to us a little bit about Shrinks?
Jonas (22:44)
Yes, yeah that is called Sphinx Plus, yeah.
yeah. So, shrinks is, I mean, it’s a relatively straightforward idea. I’m not sure if we’re the first one who had it, and it’s one of the outcomes, I think, of this ⁓ research as well. Maybe I need to take a step back and explain how hash-based signatures work, and for that, I first need to explain the concept of a ⁓ one-time signature scheme. So, one-time signature scheme, ⁓
allows you to create a public key and then you can sign with a message with it and you can verify the signature but you can only sign a single message if you sign two different messages then an attacker will be able to forge a signature
So ⁓ the way that hash based signatures are then constructed out from one time signatures is that you build this ⁓ Merkle tree. Merkle tree, maybe people are familiar from it in Bitcoin, where you have sort of a list, a long list of many ⁓ one time signature schemes. then in the, when you, the first signature you produce, you use the first public key from the first one time signature.
then you use the second public key, then the third and so on. ⁓ So ⁓ this is ⁓ essentially how a scheme works that is called XMSS, something extended Merkel, something, something signing scheme, I guess. ⁓ And this ⁓ has…
Compared to Sphinx, this has this big downside that it’s so-called stateful. And this is a very kind of technical thing that probably have a hard time to get across. ⁓ what you see is when I say the first, you produce the first signature with your first one-time public key, the second with your second one-time public key, you need to remember that you’ve already signed with the first one, right? You have this counter that increases.
Stephan Livera (25:00)
because the premise is
we don’t want to re-sign again with that same key. And yeah, so just from your paper, ex-MSS, Extended Merkel Signature Scheme, just for the theme. But I guess what you’re getting at is this idea of every Bitcoin wallet, software, hardware would need some way of managing the state now, to sort of remember, yes, I already signed with key one, so don’t use that one. Yes, I already signed with key two, don’t use that one. Use number three or whatever. But I guess it gets more complicated.
Jonas (25:03)
Yes, yes, and that is this.
Yeah.
Yep.
Stephan Livera (25:29)
complicated when we’re talking about. I’ve already signed up to 7,987. Sign with 7,988 and more complicated examples, right?
Jonas (25:35)
I think
that wouldn’t be a problem because computer takes care of large number. The problem is that you store the state in your wallet file, let’s say on your disk, you produce a backup, you continue to use Bitcoin as normally produced transactions, sign or whatever, and then your computer crashes, breaks down, you need to restore your backup, and then you’re reusing that old state.
Stephan Livera (26:02)
And if it’s an old backup, now you could be in trouble,
right? Right. And this is maybe similar to like, even like lightning in lightning, this idea of like, if you try to resize sign with an old state, you know, it’s kind of sort of maybe loosely analogous there. So as I’m understanding, yeah, and so as I’m understanding the idea of shrinks is like, it’s you’re doing like a hybrid, it’s like, in the happy path of the good case, you’re doing stateful, and then you’re having like a stateless backup, but the cost of that is you’re paying or you’re
Jonas (26:05)
Yeah, so that is the big problem with statefulness.
Yeah, I think it’s pretty similar, yeah.
Stephan Livera (26:32)
the transaction size is much larger. Is that right?
Jonas (26:35)
Yes, that is right.
But first I have to say, so these one-time signatures, they are ⁓ relatively small, so they are just 250 bytes, a single one of them. ⁓ But like, we probably, since…
Stephan Livera (26:45)
Okay.
Jonas (26:51)
So there’s this ⁓ potential ⁓ thing we could do is we just deploy one time signature scheme on Bitcoin, right? And I said that addresses shouldn’t be reused, so just use this one time signature scheme, but there are cases where you need multiple signatures. So that wouldn’t be adequate. So we need multiple signatures. And ⁓ what is also missing is that, ⁓ so far in the explanation is that you build this Merkle tree of public keys,
And now anytime you want to sign for one of the leaves of this tree, you not only need to produce the signature, but you also need to produce a Merkel proof to show that this public key is included in the in the Merkel tree.
Stephan Livera (27:36)
Okay, so
that’s also expanding the size of the transaction then.
Jonas (27:39)
Yes, yes. So what we do then is we sort of optimize the layout of the tree such that the first public key is very near to the top. The second one is just below it. Third one is just below. So the more signatures you create, the more expensive it gets. But the advantage is that for the first signature, the cost is essentially just.
the cost of this one-time ⁓ signature scheme. So just ⁓ the one-time signature is pretty small, 270 bytes something. So that’s what we use for the stateful part.
Okay, so we could deploy that, but that still has the problem that you cannot at all produce a backup that would always be insecure. Because, ⁓ or no static backup, I should say, right? So right now, like we do backups, we write down words on a piece of paper. That wouldn’t be possible anymore because anytime you ⁓ would make a signature, you would have to
update your piece of paper and add the counter to the paper. that’s impractical. So what we can do then, and that is shrinks, we combine the stateful scheme, which is very efficient, and the stateless scheme. Meaning that on the device where we have the state, we can use this optimized stateful signature scheme.
Stephan Livera (28:48)
Right, impractical, yeah.
Jonas (29:10)
but on a device where the seed has been imported that does not know the state, we would use the stateful scheme. So the stateful scheme is more ⁓ costly, it’s larger size, like three to four kilobytes, depending on what exact scheme we choose, but at least it’s possible to have a backup and recover from it. And in the optimal case, signatures are very small. So that is, shrinks essentially. Big question is, ⁓ even
even if we have to set up our devices capable of holding state ⁓ securely in that way. For let’s say for hardware wallets that seems to be possible.
Because hardware wallets, they don’t give the user the ability to access the disk or whatever ⁓ for ⁓ for desktop wallets or mobile wallets, I am less Certain about that because like if you just write it to a file as I said the wallet file just doesn’t work because users will will back it up or like
Stephan Livera (30:15)
Right, because they could lose that or they could
or what some people do is they might have the same wallet loaded on like two different computers or like one on a mobile one on the computer and then if they fall out of sync and then again you run into that same problem of signing with you know a key that you’ve already used before in the state full context which is you could lose your money then.
Jonas (30:20)
Yep.
Yep.
Yeah, right, so in this entire space of trade-offs, shrinks ⁓ is very optimal in terms of cost, in terms of signature size, verification cost, signing cost, but you have this statefulness problem.
Stephan Livera (30:56)
to deal with, okay. And so it would be like a new paradigm that people would have to manage and maybe in certain contexts it could be managed like maybe if it’s like an always on lightning node or something like that, in that context it might make sense but then for like the deep cold multi-sig sort of thing then maybe you need like the stateless backup in that case. And then the other aspect of it is
Jonas (31:08)
Right.
Stephan Livera (31:24)
would we still have access to things like threshold multi-seq, right? So two of three, three of five, like we would still have that.
Jonas (31:31)
Yeah, so that was another question that we had when we started this paper is ⁓ all these nice advanced signature or not, cryptographic schemes that we can use today from what do we have? We have Taproot, we have music multi-signature, frost threshold signatures, we have silent payments, ⁓ and we have signature aggregation.
Stephan Livera (31:54)
Even like atomic submarine
swaps and atomic payments like atomic swaps
Jonas (31:58)
Adapter signatures.
Yep adapter signatures will be one. So can we
Stephan Livera (32:03)
So these are all out the
window in the quantum world. Or at least in the hash-based world. In the hash-based world, those are out the window. Maybe in lattice-based signatures, is it different or?
Jonas (32:06)
not necessarily in the…
Yep.
So in let us base signatures, it’s different. So that was one of the results also for me because I thought, maybe there’s thing here or there that we could do that people in the academic community haven’t looked at because few people look at what we are interested in in Bitcoin. ⁓ We found some tiny optimizations that are probably not worth the implementation complexity. I would say that ⁓ HD wallets, have forgotten HD wallets would also not
not really ⁓ work in the way they do. So ⁓ that doesn’t work anymore. So we lose some of the efficiency gains that we have had or that we have right now ⁓ with classical signature schemes. the lattice world, since ⁓ lattice… so hashes you can just imagine, they are these ⁓ garbling machines that ⁓ take the input and produce some random looking output.
Lettices, lettices, lettice-based signature schemes. They are based on an assumption, mathematical assumption that has a lot more structure to it, more similar to what we’re using today and there exists somewhat equivalent things to multi signatures and threshold signatures. They also have downsides compared to what we have today. But right now at Blockstream Research we actually have a project looking into lettice-based signatures.
Are they practical for Bitcoin and ⁓ can we are these advanced constructions like multi signatures threshold signatures? Really practical
Stephan Livera (33:57)
Okay, yeah, so I guess maybe we’ll have to talk about the lattice ones in another podcast once you do another paper for that one. So in the hash based world, so let’s just stay in hash based world for now.
There’s a lot of things we’re losing there, right? Like HD wallets, hierarchical deterministic wallets, this idea that you can ⁓ easily input. So let’s say right now today, if I make a cold card or whatever, I make an output descriptor and have a watch only wallet and have the computer able to generate new receiving addresses while keeping, let’s say, the cold card or the hardware wallet somewhere else, we’re kind of losing a bit of that, although maybe there’s some other little bits and pieces you can sort of…
Get but yeah, as you said a lot of the ⁓ Fancy crypto tricks that you know you and other guys have come up with we would lose some of those so for example even in the silent payments Context my understanding is At least today with some payments people are computing a shared secret ⁓ and the hypothetical quantum adversary who sees he could recompute that shared secret and then go back and link the payments like historically
So that would be like maybe another example where the quantum adversary could like pwn you from a privacy perspective of knowing, hey, this is Jonas’ silent payments address. I know he took all these payments because I’ve recomputed that shared secret using hypothetically the quantum computer. ⁓ So these are things we have to, guess.
Jonas (35:26)
Yeah, that is
for sure a problem. ⁓ So generally these types of attacks are called, I think, and decrypt later. Store now, decrypt later. Because what you could also do is right now you store all the web traffic and then later you decrypt everything that has not been moved to a post-quantum scheme. And in Bitcoin you can do exactly the same thing. mean, signed payments are even worse. Yeah, you don’t need…
Stephan Livera (35:38)
Right.
Right, because everything’s on chain in Bitcoin, right? So it’s all there anyway. So you don’t even have to store it. It’s on the chain,
right?
Jonas (35:55)
Yeah, right.
⁓ Bitcoin also uses ⁓ encryption on the peer-to-peer layer.
to ⁓ protect against a global passive adversary that just listens to all connections and that would also be affected by a quantum computer because it uses the same, a very similar method to ⁓ compute a shared secret that would also be vulnerable to a quantum computer. So an attacker that just stores all this data could also later decrypt it and maybe make use of it.
Stephan Livera (36:31)
I see. Yeah. And so I guess this is kind of there was like a point of contention in some of the online debates of saying people saying, Bitcoin doesn’t use encryption. What they mean there is more like in the public and private key cryptography, it’s more like you’re I guess, would you say you’re using it more for authentication currently, not encryption. But the but there is encryption at the P2P level, which is another like a separate thing what we’re talking about, right?
Jonas (36:49)
Yes. Yep.
Yeah, yeah,
there’s also encryption on the lightning network, for example, that would be affected.
Stephan Livera (37:00)
Right, okay
yeah, well there you go, that’s another one. So I guess, would, the hash-based world of post-quantum cryptography, is lightning fine? Like, can we still do lightning but just in a different way?
Jonas (37:15)
⁓ So I don’t think that people have really looked really deep into it ⁓ but I believe it’s pretty straightforward that lightning would work still. ⁓ You would need to replace a cryptographic scheme here or there and that has downsides for example size downsides your ⁓ opening closing a channel
probably be more expensive at least if you use hash based signatures. But I don’t see a reason why it would not work in principle.
Stephan Livera (37:50)
I see. then, what was I gonna say? So now one other thing that like, we kind of, you were touching on this before, you were mentioning, anything that relies on adapter signatures, we lose that because that relies on some like fancy crypto tweaking stuff, right? And one of the things that, as I understand, uses that is like submarine swaps and atomic swapping. So even things like cross-chain swapping, like things that like, let’s say bolts.exchange or… ⁓
people who are doing like on-chain to off-chain swapping, the thing that makes that atomic, isn’t that the adapter signature? So I guess we would need some new form of that.
Jonas (38:26)
⁓
I mean, swaps can still work. ⁓ The adapter signatures are really just an optimization to swaps that we could use. The classical swaps, yeah, the classical swaps, actually just use a hash and a signature.
Stephan Livera (38:36)
to make it easier. Okay, so we could do some other form of swapping. Okay.
Jonas (38:43)
Then the sort of advantage of adapter signatures was then or is that you don’t need these tools You don’t need an extra hash which is ⁓ more efficient and also more private on chain So we’d lose that
Stephan Livera (38:43)
okay.
I see. Okay, so we don’t lose like cross-chain swapping
or atomic swapping per se. We would just have to like, it would be like a new thing.
Jonas (39:01)
Yeah, and also
since you brought up ⁓ HD ⁓
We don’t lose the entirety of HD, so from a single seed, you can still derive as many private keys as you want and in a hierarchical way. You really just lose what you explained, which is you have a software wallet that has the XPub and from the XPub, they can just by themselves generate new addresses and then scan for those addresses, scan the chain for those addresses. What needs, right.
Stephan Livera (39:33)
Right, or what’s known colloquially as a watch-only wallet nowadays,
we would kind of lose that aspect of it.
Jonas (39:38)
Right, so
how it would work then is that the hardware wallet would just pre-generate a lot of public keys or addresses and then send megabytes of public keys and addresses to the software wallet and the software wallet can still be watch only, but it’s maybe at some point ⁓ it doesn’t have enough addresses or it’s out of addresses to look for so it needs to ask the hardware wallet again, please generate no more.
Stephan Livera (39:48)
I see.
would have to watch those addresses now.
I see. Yeah. Yeah. Yeah. I get what you’re So we’d have to have a setup where like
maybe maybe it does like a hundred addresses on your computer that you can watch and then once you once you’ve hit your 100 Okay, now get back go back down there get your hardware wallet out get another generate the next hundred addresses and give that back to the software world to do the watch only part of it
Jonas (40:09)
Yeah.
Yeah.
Right, right, but
addresses or public keys, they’re pretty small, so it would be easy to use more than just 100. It’s just 32, yeah, yeah. I you can store some megabytes of public keys, I guess, on your software wallet without any issues.
Stephan Livera (40:27)
Okay, so it could be like thousands or something, right? Yeah.
Yeah. But I guess another
obvious corollary is we’re going to need new hardware wallets, right? We’re going to need because a lot of hardware wallets now for security reasons are intentionally underpowered. And I think, you know, like some of the hardware wallet makers have said that the reason is for security purposes. So that’s like another thing of like, how what are we going to do about the security of hardware wallets in that were in the post quantum world?
Jonas (40:56)
Yeah.
Yeah, that is another interesting dimension. So far we’ve only really talked about signature size, but really another aspect is how long does it take to ⁓ produce a signature? ⁓ on regular hardware wallets, believe it’s depending on what kind of hardware wallet, I mean there are multiple types, but like with these relatively low powered devices that are not smart cards, but low powered CPUs, would take maybe
Stephan Livera (41:06)
like computational capacity. Yeah.
Jonas (41:27)
two minutes to produce a single Sphinx plus signature. So that is not great.
Stephan Livera (41:33)
yeah, that’s a bit of a downside too, yeah.
Jonas (41:35)
But
⁓ they can deal with it, which I think is good news. And I suppose once ⁓ people actually want to produce those signatures, then hardware wallet manufacturers, can ship and sell hardware that is specifically designed for hash-based signatures. So they could have some extra hardware that is just very good at computing those hashes to get those numbers down.
think that is a realistic possibility. The other aspect is verification time.
Stephan Livera (42:10)
Yeah, interesting. so, yeah.
Jonas (42:14)
There’s not just signing time, there’s also verification time. Verification time affects all nodes because they need to verify the blockchain, including the signatures. And we don’t want verification time to go up by too much because in general, want that ⁓ nodes should not require, running a node shouldn’t require enormous resources for decentralization, et cetera. And those hash-based signatures, ⁓
Stephan Livera (42:15)
Yeah.
Jonas (42:42)
verifying a single hash based signature is more expensive than verifying the Schnorr signatures we have right now.
Stephan Livera (42:48)
So in the Shrinks,
let’s say, paradigm, do you know roughly how much, is it like a 5x more, 10x more? Do you have a rough idea?
Jonas (42:58)
I would think in the shrinks paradigm if they use the optimize, the optimized path, so if you have the state and everything then it should be pretty, the verification cost should be comparable to to Shnor signatures. There shouldn’t be a big difference. If they have to use the stateful path then you think maybe.
Stephan Livera (43:11)
what we use today. Gotcha.
Jonas (43:25)
maybe 50 times more expensive. Yeah, it’s also much larger. So per byte, yeah, so it’s also much larger. Per byte, the cost is about the same.
Stephan Livera (43:27)
50 times. Okay.
okay, I get you, get you because… ⁓
I see, yeah, yeah. because then like, if a typical Bitcoin block today, I don’t know the average, but, you know, call it 2 megs or 1.8 megs or something like that range. And then, I guess, I mean, while we’re here, let’s talk a bit about the block size aspect of this because, okay, just for example sake, let’s say we go, we went, we, as a community, we all agreed on shrinks and we said, okay, we’re doing shrinks.
As he said, it’s like what 270 bytes or something? So we’re talking like maybe five or six X what a current signature size is
Jonas (44:06)
Yep, in the best case.
Yes, so 64 bytes is the current signature size. Yeah, it would be four to five times. Let’s say five times.
Stephan Livera (44:20)
Yeah, okay. So let’s say like 5x.
Does that mean kind of loosely speaking, we’re taking, if we keep the block size the same, like 4 million weight units, et cetera, does that mean we’re going to have like approximately one fifth the capacity for transactions like loosely?
Jonas (44:38)
Mmm, I don’t think so because there’s also other parts of the transactions right that don’t change So it really only changed the signature part part. So I would expect like much less than five times
Stephan Livera (44:49)
Gotcha. But the signature is one of the bigger parts of the transaction,
right?
Jonas (44:52)
Yeah, it would become the big, well, we have these transaction outputs, they are large inputs referencing previous outputs, so they are all pretty large and they are not affected by the witness discount. So I haven’t run the, it should be pretty easy to run the numbers, but it would be, I think we would be able to support between a half of the, 50 % of the transactions that we have right now and 100 % somewhere in that range, or maybe 25.
Stephan Livera (45:19)
okay. So it’s not like a crazy
downgrade, you know, it’s going to, and to be fair, that’s also in the stateful case, because if there’s a lot of people who are doing the stateless size of transaction, then we’re really losing a lot of our transaction capacity per block. Yeah.
Jonas (45:37)
Yes, yep, yep, that is correct.
Stephan Livera (45:39)
Because those stateless ones are much bigger, as you said, they’re like eight kilobytes or something like that, right?
Jonas (45:44)
Yeah, four kilobytes if we use the optimized ones that we discuss in the paper. But if the block size stays the same, then the verification cost per block will also stay roughly the same to what we have today.
Stephan Livera (45:50)
Okay.
Okay, so that could be yeah, and so I
guess that’s the other thing the community obviously that was very controversial in the 2015 to 2017 era the block size wars Do you think the community should reopen that conversation around quantum and say well if we’re come out with Shrinks are we gonna raise the size block size again to compensate for that? Like does that mean we go to like I don’t know 8 million weight units or what do you like? Do think that is?
I guess, obviously I understand this could be a controversial thing, but do you think it is worthwhile to talk about?
Jonas (46:34)
I, yeah, for sure. think it’s worth worthwhile to talk about. mean, the environment is always changing that Bitcoin operates in. There’s and therefore Bitcoin must adapt in any way. the question is, what is the risk of trying to find consensus on a new
block size and can that even be done? I think it can, maybe with some arguments. yeah, think we should, it makes sense to talk about it. But in terms of exact sizes or something, I think that’s way too early right now.
Stephan Livera (47:10)
I
But yeah, I mean, just do you, guess here’s the other question in terms of efficiency and optimizations, as you mentioned, there are still researchers finding optimizations. Obviously you and others are looking at Bitcoin focused optimizations. how, where are we in that, let’s say curve or cycle? Like, do you think there’s, there’s some more optimizations to come or are we sort of, ⁓ you know, like, you know, like even in Bitcoin land, like the ASICs
that we got, there was, you in those first few years of ASICs, there was like a pretty, you know, pretty big improvement. And then after a while, like the improvement slowed down a bit. Do you have a sense of what that is in quantum, post quantum crypto for Bitcoin?
Jonas (47:49)
Mmm.
It’s almost as hard as giving an estimate for a quantum computer, right? These timelines for technology are just difficult. I don’t really expect a breakthrough in hash-based signatures. Letters-based signatures, they have a long history already, so it’s pretty hard to get up to speed with the current state-of-the-art schemes because they just use so many tricks.
Stephan Livera (48:00)
Yeah.
Jonas (48:24)
expect there’s something there. For example, signature aggregation, which is super interesting topic. Now we’ve only talked about
Essentially using the Bitcoin the same way as we do today, but you could also imagine that ⁓ instead of just like right now right we have a signature per coin that that we’re spending and ⁓ Signature aggregation would mean that we would instead have a single signature for a single transaction that just authorizes all of the coins That are spent in the transaction so using Bitcoin different than we do today that that would be an option
if this aggregate signature in the end would be much smaller than the sum of the individual signatures.
In hash-based signature schemes, unfortunately, not really possible. In lattice-based signature schemes, maybe I haven’t seen a signature aggregation. Or they exist signature aggregation schemes, but I think there’s more there for sure to be ⁓ explored. And then maybe if we only have a signature per transaction that is relatively large, but somehow we’re able to all produce… Yeah.
Stephan Livera (49:37)
We’re kind of amortizing it across a lot of
going into that transaction, let’s say.
Jonas (49:43)
produce transactions collaboratively, then maybe that would also get rid of some of those problems with large signatures. And also, ⁓ one other aspect is that it’s not really an either or hash-based signatures or lattice-based signatures, also possible to use to implement both ⁓ for the Bitcoin protocol.
Obviously also comes with downsides additional complexity maintenance cost it has some It reduces privacy a little bit because then you have wallets that only support hash based signatures others only support less with Yep, yeah So another possibility in this big space of options
Stephan Livera (50:20)
Right, there could be like fingerprinting based on which one you use.
Yeah,
but perhaps that’s also part of the challenge is that there’s such a wide, let’s say, design space of what’s theoretically possible. Does that make it hard for us as a quote unquote Bitcoin community, node runners, whatever you want to call us, whatever, you know, people who are doing Bitcoin stuff and actually take it seriously to come to agreement on something, right? Because we have to like be able to agree on, so maybe sort of like, what is the minimum viable thing that we can all agree on and say, yeah, that’s the path forward.
Jonas (50:53)
Yeah, right. mean that is in an ideal world I guess that wouldn’t be the case because at some point we would just just use one of the schemes or whatever and that’s better than having nothing which I think is possible in an emergency situation. In emergency situation we could use Sphinx Plus as standardized tomorrow and I think wouldn’t be that hard to get ⁓ a consensus on it if there was a real risk although it’s always hard to estimate what the risk
But yeah, I think that will be a huge challenge potentially to agree on one of those schemes just because the space of options is just enormous. And all of them affect ⁓ Bitcoin users in one way or another. That is the big problem.
Stephan Livera (51:38)
I see.
Yeah. And then
even with multiple schemes, does that create like, I don’t know, additional verification costs? Or would you, or would you just see it like, well, we still limit it, we’re still bounded by block size. And therefore that’s kind of like the real limiter, the rate limiter in terms of people, I don’t know, just putting in like transactions, like, cause as I’m sure you, you are.
more aware of this than I am, but historically there have been bugs or things that related or let’s say vulnerabilities that related to people who could craft a malicious transaction or a malicious block that takes a very long time for like a low power device or even a standard power device to actually validate. And then that became like, is that a DOS vector?
Jonas (52:21)
Mm-hmm.
⁓
I mean, I don’t really think that would be the case for these kinds of signatures because you just run the verification algorithm and it usually doesn’t have any additional randomness or something or it should have a pretty clear upper bound how long it takes to run. But I think it’s always a risk to introduce new stuff to Bitcoin, especially if it’s as complex as a new signature scheme. So one of the advantages of
of using a standardized scheme for example is that ⁓ good implementations already exist. ⁓ They haven’t been written for a consensus system like Bitcoin, which is its own challenge, but they have been very well written and they are being used in production.
So in principle it wouldn’t be unthinkable to just pick one of them. And when I say they are not optimized for ⁓ consensus system is that… ⁓
Bitcoin we have this additional challenge which ⁓ usual cryptographic libraries don’t have is that we need to have this sort of backward compatibility when releasing a new version so a signature that is valid with one version shouldn’t be become invalid with with the next version or even worse the other way around the signature was invalid will become valid usually that’s not such a big deal if you’re just signing software or
use it for the web, in Bitcoin this could result in chain splits and consensus failure. So that is an additional risk that you get when introducing ⁓ complex additional schemes to Bitcoin.
Stephan Livera (54:06)
I see.
Yeah, so summarizing then, Sphinx Plus is the, let’s say, more standardized, like in the NIST, N-I-S-T, in that world, it’s kind of standardized and it’s stateless, but the downside is it’s very large. It’s like eight kilobytes, which is massive in Bitcoin transaction land. ⁓ But the, let’s say, Bitcoin optimized version that you and others are working on is Sphinx. And what would be required for that to become?
You know, like, does it just need like more review and research for people to sort of come together and agree, okay, we Shrinks is a good Bitcoin optimized form of Sphinx Plus or what?
Jonas (54:48)
Yeah, so I wouldn’t say that shrinks is our main proposal. mean, in the paper what we’re doing, we’re looking mainly at variants of Sphinx. And one of the results that we have is a Python script where you can play around with different parameters and it will then output the cost in terms of size and verification and signing time.
Stephan Livera (55:14)
See.
Jonas (55:15)
And even there, if you just look at that, it’s also quite difficult to just pick one scheme. So one of the open questions was, for example, how does it behave with hardware wallets? Although I think that’s not such a big deal right now, because in the future we could have hardware acceleration for doing ⁓ fast hashes. In terms of shrinks, the question is, think ⁓ hardware wallet manufacturers, do they think they can keep state security? So that would be an
interesting sort of input that we’re looking for.
Stephan Livera (55:52)
Yeah, right. And because you can imagine there might be failure cases where, you know, like a device can brick and then you need to recover or like maybe it could it could it or could that be like a vector for attackers like security hackers who are like, you know, they try to play with things like power analysis of like turn it off and on or do things to kind of mess with the device to try to make it do something different. And in that process, could you lose your state from that? I don’t know. But maybe that’s like a more of a
Jonas (56:06)
Yep.
Stephan Livera (56:20)
extreme case that maybe the hardware wallet manufacturers don’t build for that because they’re just building for the standard case. But I guess it is a security consideration, right? Nevertheless.
Jonas (56:28)
Right? Yeah.
But one of the major pushbacks that we got for this work, which I think makes sense from perspective is just that, why don’t you just use the standardized version because that has already these libraries and it will have support by Apple or whatever and by HSM manufacturers and so on. ⁓
Why would you invent your own thing for Bitcoin? And the answer to that I think is just that…
I think the limited resource is really the resources, the verification resources that we have, and network bandwidth that we have on our nodes. And if we can reduce the signature size by 50%, I think that’s pretty significant. And I hope the limit is not designing the secure libraries and writing standards. Sure, that is very resource intensive, but I feel like the sort of resources
on the notes are the more significant limit than our manpower to solve these problems and write good code.
Stephan Livera (57:41)
I see. Yeah. And as you said, coming back to the whole block size and controversiality or how controversial that could be, if we’re talking about like eight kilobytes or four kilobytes even, that’s massive from a Bitcoin transaction. from, you know, can you give people a sense that like transactions today are more like a few hundred bytes, right? So this would be like a very big decrease in our capacity unless we also pair it with, okay, we did Sphinx Plus, plus a big, quite a substantial block size increase, which would also be very controversial and
Jonas (57:58)
Yep.
Stephan Livera (58:11)
Unlike, maybe unlike, I don’t know, hard to say. Maybe it’s unlikely to be accepted, like a very big block size increase, like a 5x or a 10x block size increase.
Jonas (58:17)
Hmm.
Yeah Yeah, I mean and lattice-based signatures for example. They are also pretty large So they would be in the three to four kilobyte So shrinks if statefulness works is actually the smallest ⁓ post quantum signature scheme outside of like ⁓ schemes that rely on ⁓ rather crap more more crazy mathematical assumptions
Stephan Livera (58:45)
like
novel cryptographic assumptions kind of territory. Okay. Now in terms of, I know this wasn’t like part of your paper, but obviously given your depth of work and knowledge of Bitcoin, can you talk to us a little bit about what a transition might look like? Is it like, you know, something like BIP 360 and then people have to like spend out of their old, you know, outputs into the new quantum resistant outputs? I know there are different
ideas around that also, like some people have this idea of having like, I think it was Matt Corallo was talking about this idea, or maybe it was his idea of like having, you know, what if you had people having like a taproot script path with their quantum resistant thing in there, and you keep using the key path for now, and then once hypothetical Q day comes and the quantum computer is confirmed, at that point, you would have to disable the key path and then only have
Jonas (59:21)
Mm-hmm.
Stephan Livera (59:41)
script path, but this might enable like a gradual transition. I don’t know, do you have any thoughts to share on that transition aspect?
Jonas (59:49)
Yeah,
so yeah, right, so there’s a bib360 and bib360 has evolved quite a lot ⁓ since it was first proposed.
What it does is it allows you to send your coins essentially lock them just by taproot Merkle tree So it’s very similar to taproot except except that you have no key spend path So you just have a essentially the Merkle root which is a hash in the output and then if you want to spend you need to ⁓ reveal one of those ⁓ leaves in this Merkle root which ⁓ then ⁓ shows gives you the spending conditions and then you need to provide a
signature for that. BIP-360 by itself does not provide ⁓ quantum security only against ⁓ long exposure attacks because it does not propose a post quantum signature scheme. ⁓
So that is one possibility. The downside of that is that if people would move to BIP360, then they would lose all of the performance gains that we got with Taproot in the first place, essentially. Not all of them still have the Merkle Tree, but you couldn’t do any, the ⁓ key spend path was just more efficient than ⁓ using the Merkle Tree to spend, and you had… ⁓
music, frost, etc. directly on the keyspan path so we lose that. But it’s a possibility. BIP 360 is not complete as I said but sure that is a possibility and another possibility is what you mentioned this idea popularized by Matt Corello. Unfortunately it does not have a snappy name or BIP associated with it so I’m struggling to find a good name for it but I think it’s another
Stephan Livera (1:01:19)
We would lose all that.
Jonas (1:01:46)
viable approach ⁓ where ⁓ you just use taproot ⁓ as is right now and then only once the quantum computer appearance becomes imminent you disable the key path and that means that you need to have some fallback always in the script path such that once the key path is ⁓
is disabled you can still spend your coin using a script path. And the script path could also then use some post-quantum signature scheme opcode that might be eventually introduced in Bitcoin. The advantage of that is you can use all the Taproot features until the Q-Day comes. ⁓
Stephan Livera (1:02:41)
I see. Yeah. So I guess there’s different options on exactly how the community goes about this upgrade. ⁓ So yeah, coming back to what we were saying before, it’s going to be sort of a challenge of getting everyone to coordinate on exactly what we’re doing and when, and will there be multiple soft forks required, right? So if, so I guess just talking it out, you tell me if I’m getting this wrong, but as an example, one way could be,
maybe if bit 360 was sort of paired with like one of these schemes, whether it’s Sphinx Plus or Shrinks or something, and then it would just be like one soft fork to get that in. Or it might be two soft forks if there’s like one for bit 360 and another to sort of bring in the particular scheme. ⁓ And then there might even be, again, controversial, but there might be another one around burning.
you know, Satoshi’s coins or the vulnerable coins per se, maybe it’s not really accurate or precise to just say, yeah, Satoshi’s coins, but the quantum vulnerable coins might end up getting burned or frozen in some way. ⁓ And of course there’ll be arguments about that too, because there’ll be some who say, well, you should never seize coins and it’s better to quote unquote, let the chips fall where they may on those vulnerable coins. ⁓ So yeah.
Jonas (1:04:00)
Yeah, I think that will actually be
the much ⁓ bigger discussion that might have quite an impact on the Bitcoin space and even lead to a split.
Stephan Livera (1:04:10)
Right.
Yeah. And so I guess in such a scenario, there could even be like, if it’s like, if it really gets extreme, there could be like an intentional chain split. And just like we saw in the 2017 kind of SegWit2X and block size wars, like in the SegWit2X case, Bitfinex literally had B1X and B2X and people were trading one token against the other. And so maybe in that world, there would be like kind of the burn.
Burn vulnerable coins fork and then the no burning let the chips fall where they may fork and they may even trade against each other and so in that scenario, I guess hypothetically if you want to be safe you just kind of sit and have hold both sides of the fork and sort of wait for the dust to settle and then be like, okay, well that’s the true Bitcoin. This is the one that won and yeah. Yeah. Or just like a permanent chain fork split and you know,
Jonas (1:04:43)
Yep.
or it can become permanent.
Yeah.
Stephan Livera (1:05:06)
like Bcash and BSV and whatever, like they just, but I think in practice, one of the sides would probably win and then that would be quote unquote, the real Bitcoin, but who knows?
Jonas (1:05:08)
Yeah.
Yeah, I guess so too.
Stephan Livera (1:05:19)
Yeah. Anything else on like transition aspects? ⁓ I mean, what about the time? Like people have tried to estimate, okay, is it going to be like half a year or a year or years worth of time? Like just literally the packing people’s transactions in to get, you know, from the old, you know, the current scheme today into the quantum resistant or quantum secure scheme. That itself could take time depending on if we have a block size increase or not or…
Jonas (1:05:36)
Mm.
Stephan Livera (1:05:47)
whatever, the size of the new scheme.
Jonas (1:05:50)
That’s actually a good question. I haven’t run the numbers on that. I don’t know. But that’s a good question. The minimum of time you need, assuming everyone would migrate, or at least most of them, and all the time.
Stephan Livera (1:06:03)
And is it going to be
like chaos and cacophony of like some people are like putting through transactions at like crazy high because they want to get through first and make sure their stuff is safe? I mean, who knows what could happen there. Yeah.
Jonas (1:06:13)
Yeah, so that is one of
the advantages of the MedCorello Taproot approach, if you want to call it like that. It’s just that you could start to use this today. Just add an additional ⁓ Merkle ⁓ path to your Taproot tree ⁓ with a post-quantum signature scheme, assuming this was deployed. And then you can use your…
Stephan Livera (1:06:19)
Yeah. Yeah.
It’s a gradual transition, yeah.
Jonas (1:06:41)
your wallet as you do today. Yeah. ⁓ So that would be a pretty gradual approach. But of course we never know how many people have actually migrated in that case.
Stephan Livera (1:06:41)
your wallet as normal today until hypothetical Q day and you kind of burn the key path.
Yeah, so there’s a benefit to that.
Yeah. And then that’s the other
problem as well of like today there are millions of coins vulnerable and you, guess, obviously step one is, guys, like don’t reuse addresses, like learn to, you know, you don’t do that. And I guess as, if we, okay, and that’s the other thing. If it’s like a sudden thing or it’s a gradual break in the quantum side, like in terms of quantum computing coming, because if it’s a gradual thing, then you would expect over time,
that 6 million coins that’s currently vulnerable, a lot of those people will start transitioning out of the reused addresses and out of the vulnerable addresses, at least if they still have the keys, like maybe Satoshi’s dead, who knows, so maybe those coins don’t, but a lot of the other coins should transition, and at least any professionally managed coins would, right? Because that’s the other thing. It’s a bit of a misnomer that people think, Satoshi has a million coins. Really what that is is this quote unquote Patoshi mining pattern.
Jonas (1:07:31)
Hmm.
Stephan Livera (1:07:52)
And they’re stored in lots of many, many, many outputs. So it’s not that the Quantum Coheditor is just gonna do like one round of hacking and just get like million coins. It’s like they would have to go through each of those. The bigger juicy targets would be the custodians who have like, you know, like 50,000 coins or a hundred thousand coins on one, like in one UTXO. ⁓ That would be the real juicy target for a Quantum Hacker per se.
Jonas (1:08:05)
Right.
Right. So yeah, and I think this view that ⁓ quantum computer comes gradually or at one point in time is very idealistic because we will never know and there will be a lot of uncertainty that we can get into the quantum computing war games that project 11 has written about. It’s pretty interesting, but it seems to be more realistic to me that we will have a lot of uncertainty and it will be very messy.
quantum computers and there might even be also lot of fad and people ⁓ can financially take advantage by using that fad and claiming they have broken a Bitcoin public key or something like that but they haven’t but they can fake it convincingly. ⁓
Even though I work on this post-quantum thing, ideally it wouldn’t happen because then I don’t need to be involved in all those discussions regarding ⁓ the switch to post-quantum stuff.
Stephan Livera (1:09:21)
Yeah, so it’s going to be a challenging thing. So I guess my gut feel is we’re probably going to have to look at what is the sort of minimum viable, what is the minimal thing that everyone can just kind of agree more easily agree on or what’s like the sort of quote unquote shelling point that we can all come to and say, yeah, that’s the, know, maybe, maybe that ends up being like, okay, pip 360 and some particular scheme, whether it’s Sphinx Plus or Sphinx Plus and just…
Let the chips fall where they may, right? Like it’s your responsibility. Okay, it’s like here’s your quantum secure thing. If you want it, use it. Or if you’re a quantum denier, don’t use it and let the chips fall where they may. No freezing, no burning. Just, you know, that’s it. Maybe that’s like the minimal sort of thing. But even that, are we going to do a block size increase for that? Like to compensate for the loss of transactional capacity? Don’t know.
Jonas (1:09:59)
Hmm.
Or our layer 2s and rollups and arcs are good enough to just deal with this event.
Stephan Livera (1:10:25)
Right, to just take 50 % less transactional capacity or even less
or something. Yeah.
Jonas (1:10:31)
Yeah, so a lot of hypotheticals, really hard to project this into the future.
Stephan Livera (1:10:34)
Yeah.
Yeah. Okay. Fair enough. But at least ⁓ you know, I thank you for putting out for doing this research and at least helping us understand it a little bit better. ⁓ Any other, you know, any of anything else you think we didn’t cover that you you know, you think you really think we should talk about?
Jonas (1:10:53)
⁓ I think we covered pretty much ⁓ everything so if you want to leave one read the paper ⁓ Wondering where to best best find it find it, but you can yeah hash based signatures for Bitcoin
Stephan Livera (1:11:07)
I’ll put the links in the show notes. So don’t worry about that. So I will link that in the show notes
of course guys follow Jonas your Your handle is Nikola right and one CK le are just off the top of my head I think that’s the one so yeah, of course guys follow Jonas Keep up to date on what’s happening here And yeah, I guess we’ll leave it at that. So thank you very much for coming on the show and helping
Jonas (1:11:20)
Yep.
Stephan Livera (1:11:34)
Keep us updated, keep us educated on this. Thank you.
Jonas (1:11:37)
Yeah, awesome. Thank you.