{ "episodeId": "SLP713", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "jonas_nick": { "name": "Jonas Nick", "role": "guest", "tag": "JONAS" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.14, "text": "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. 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. The world is migrating to post quantum schemes, whether you see it or not. If you would just use the, standard- standardized signature scheme, hash based, it would be eight thousand bytes. The effect of that is that fewer transactions fit in into a block, fewer people can make transactions, potentially fees would go up quite significantly. Do they ever need more than sixteen billion, signatures for a single" }, { "speaker": "jonas_nick", "time": "00:50", "start": 49.96, "text": "public key? 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, how, you know, and of course Jonas' 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, you know, researcher and developer. He's part of the team at Blockstream Research. He's been writing papers, and we're gonna be discussing, one in particular today, but I guess we'll talk a bit more broadly about it. And I guess also of note for listeners, Jonas is also a maintainer of Libsecp256k1. So he's a maintainer of one of the to the cryptography that we already use in Bitcoin today. So just for listeners who aren't, unaware. So, Jonas, first off, welcome back to the show. Hello everyone, happy to be here. So, let's just start with a bit of your thoughts, l-on, you know, your thoughts as a cryptographer working in Bitcoin, how, how real is this risk? Like, I guess people wanna get a sense of that because there's been a lot of talk recently about new adv-uh, 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?" }, { "speaker": "stephan", "time": "02:11", "start": 130.57, "text": "Right, right. So from my perspective, what we're doing in Bitcoin, right? We have the- These coins that we authorize coins using digital signatures. And, those digital, 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...\" The curve that we depend on in, in Bitcoin is, 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, when 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 isn't secure. this has been known since the mid '90s. after the invention of Shor's algorithm that would show you how to break the security of such a curve. The only thing that is missing, would be this, this machine that is called a, a quantum computer, and that adds a little bit of unease when I write these, these kinds of papers. The question is, is it realistic whether a, 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, to become, a thing in, in- In, in the future. So, and this is what is motivating me, to work on this, on this problem." }, { "speaker": "jonas_nick", "time": "04:31", "start": 271.15, "text": "Yeah. And so, do you have any thought or research or anything you've looked at in terms of timelines or, you, you don't have any idea on what is realistic for a quanti-- for a quantum computer, co-- for a quantum computer that could break Bitcoin's cryptography? The," }, { "speaker": "stephan", "time": "04:48", "start": 287.98, "text": "the problem is, that there doesn't seem to be a consensus on, on a timeline, and it seems to be very hard To predict, these kinds of things. I mean, I am not losing sleep over it right now, I'm thinking more in a decade long timeline or something like that, la-- not as much in a three to four year, timeline where, where Bitcoin would, would really, be affected. But also we still need to, assuming a quantum computer would appear in ten years, then we still need time in between to migrate. And, as we know in Bitcoin, but- Bitcoin moves kinda slow. We need to prepare soft forks, we need to," }, { "speaker": "stephan", "time": "05:32", "start": 332.02, "text": "deploy those soft forks and, and do the-- do so securely, and all of that takes, time," }, { "speaker": "jonas_nick", "time": "05:40", "start": 339.52, "text": "time too. I see. And so from what I've seen, you see, you know, the gamut of, you know, there are people who think, \"Oh, it's coming in a few years,\" and there are other, like, legitimate quantum computing experts who think it's like twenty 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, you know, what, what, what the range of what you're seeing, some people saying. Yeah." }, { "speaker": "stephan", "time": "06:05", "start": 364.54, "text": "There, there are some really bad arguments, I think. the, 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 a fact that the world is migrating to post quantum schemes, whether you see it, or not. I mean, there are governments Government bodies that mandate the use of post quantum, schemes and, if I use my, my SSH tool for, for non-techni- the techies, that's the tool you use to, log into computers over a network, it will ta- 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, a non-quantum secure channel, and similarly, my current, like, And 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, the world is moving towards it." }, { "speaker": "jonas_nick", "time": "07:20", "start": 439.84, "text": "I see. Now, a-and I-I-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, can't 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, Way, so I think that's important. Right. That's a very important point." }, { "speaker": "stephan", "time": "07:52", "start": 472.01, "text": "Yeah, that's a very important point. I see this also all the time. Why haven't you done anything already? And the problem really is that we-- There's no alternative in the post quantum space that we could just use, for free, because any, 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 downside, pros and cons that we- We can pick, but there's no scheme that we could just, take that has exactly the same properties as the cryptographic schemes that we use right now." }, { "speaker": "jonas_nick", "time": "08:29", "start": 509.23, "text": "Gotcha. Okay. So I'm gonna do my best to try and offer a simple explanation of what we do today in Bitcoin, and you, you tell me if I'm getting anything wrong, but I'm gonna try to offer that just for listeners who are, let's say, new and trying to understand what's going on here. So 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, it's like it would take like billions and billions of years to kind of reverse out that private key from the signature that, you know, we post on chain. But in the hypothetical quantum world with the use of Shor's algorithm A quantum attacker, or once the so-called Q-Day happens, that attacker would be theoretically able to reverse out your private key from, you know, what we're posting on chain now. Is that kind of a loosely fair summary of what's happening? I think" }, { "speaker": "stephan", "time": "09:41", "start": 580.98, "text": "that's, that's a pretty fair summary. I mean, it de-- 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- Got it. And that's probably a" }, { "speaker": "jonas_nick", "time": "09:53", "start": 593.08, "text": "good point to explain the short-range attacks and the long-range attacks. So the idea is if you have at 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, you know, the qu- 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 a mempool, 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, it's, it's a much higher bar for them to execute a short range attack versus just doing a long range attack." }, { "speaker": "stephan", "time": "10:46", "start": 646.26, "text": "Yes, yes, that is right. And I think another interesting 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 isn't 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 the, the, that, no one has found such an algorithm Algorithm, so far. Right. That can bring it to like" }, { "speaker": "jonas_nick", "time": "11:23", "start": 683.29, "text": "a realistic time. I, I was researching a little bit, there's this, it's called Pollard's rho, but apparently it brings it from like two to the two hundred fifty-six down to like two to the two hundred and twenty-eight, so it's like still, yes, yes, 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, instead of being an exponential" }, { "speaker": "jonas_nick", "time": "11:50", "start": 709.7, "text": "Means it's now in the realm of possibility, as instead of like basically very, very impossible or very, very, very unlikely, yeah." }, { "speaker": "stephan", "time": "11:56", "start": 716.17, "text": "Yeah, but I was trying to say that, another angle for this type of research isn't 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, at lo- Looking this at, at this, what if the assumptions we use in Bitcoin just break down, even in the classical world? What can we do?" }, { "speaker": "jonas_nick", "time": "12:27", "start": 746.99, "text": "I see. So yeah, as, as you said, I, 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, you know, Satoshi, maybe Satoshi's dead, who knows? But, there's a lot of address reuse and instances where the coins have already had their public key exposed. and so that's also just worth, you know, understanding that there are a lot of coins already vulnerable, today. although- So maybe in the future, like if, 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." }, { "speaker": "stephan", "time": "13:28", "start": 807.62, "text": "Yeah. 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 haven't migrated to a post quantum scheme, and fortunately, that's not a, a question that cryptography has an answer to." }, { "speaker": "jonas_nick", "time": "13:49", "start": 828.84, "text": "Right. and so I guess you, as, 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 know, 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?" }, { "speaker": "stephan", "time": "14:13", "start": 852.73, "text": "Right. So I mentioned earlier that the security of the signature schemes we use today, they depend on an assumption, assumption that is that the curve isn't 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, in a post quantum world, and, one of those assumptions is that, hash, hashes are still, s-secure in against, quantum computers, mainly that they're still resi-collision resistant, or 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 can't really-- you can't 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, as you mentioned before. So still not in the realm of actual, physical, possibility. So hashes are one of the assumptions that, 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, in, in the Bitcoin space, and there exist, standardized schemes for lattices, But in our work so far, we have looked into hash-based, signatures, and 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, in Bitcoin. We use hashes to identify transactions, we use hashes to identify blocks. So if hash functions weren't secure, we arguably, we 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, and so on. So that would be potentially even worse. And these, the, this assumption is relatively conservative And also all the other, signature schemes in the post quantum world, these 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, with downsides for sure." }, { "speaker": "jonas_nick", "time": "16:51", "start": 1011.14, "text": "Got it. and so these are some of the, yeah, so do you wanna start walking us through some of the, Some of the, you know, points you explore in this paper around hash-based, you know, schemes, like what are some of the categories of scheme and what are some of the, you know, the upsides and the downsides of them?" }, { "speaker": "stephan", "time": "17:13", "start": 1033.39, "text": "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 of Standards and Technology, I think, US, US thing. They exist, they are implemented, as I said, for example, in, 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 things standardized schemes that exist a little bit to make them better suited for, the Bitcoin, for the Bitcoin use case. This was one, one of the main questions we, we started out with, when, when writing this, paper." }, { "speaker": "jonas_nick", "time": "18:14", "start": 1094.06, "text": "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, it, 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." }, { "speaker": "stephan", "time": "18:51", "start": 1131.12, "text": "Yeah, so, our current, Schnorr signatures or Schnorr signatures are sixty-four bytes and ECDSA signatures are about seventy bytes. Now, if you would just use the, standardized, signature scheme, hash based, it would be eight thousand bytes. So that is like a hundred, more than a hundred bytes. It's, I believe it's about ten, twelve, thirteen, transactions, like average transactions on the network, just with single signature. And, well, the effect of that is that fewer transactions fit in, into a block, fewer people can make transactions, potentially fees will, 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, 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 eight thousand bytes is already the, 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, I mean, we weren't, the first to think about this, but, one of the characteristics in, in Bitcoin is that We usually want to avoid reusing addresses, so we generate a, 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, on the chain. so the average number of signatures we produce for a single public key on Bitcoin, least usual in the u- U- usual cases is about one, between one and two. Sometimes you will need to use, so, you sign a transaction and then it doesn't confirm, so you need to, increase the fee, sign again." }, { "speaker": "jonas_nick", "time": "21:21", "start": 1281.45, "text": "Or, or there may be cases where you wanna like prove ownership of an address, right? That kind of thing." }, { "speaker": "stephan", "time": "21:26", "start": 1286.15, "text": "Yeah, that's, that's a good point. Or maybe you're using like 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 really. now these hash-based signatures, we can reduce them, significantly by putting a, a limit on the number of times you can sign with a single public key. So we can say, okay, with this public key, you can sign sixteen billion times. If you sign more than sixteen billion times, then, your, an attacker will be able to- Potentially, or will be able with relatively little effort to, forge a signature and steal your coins. So you must be below that limit. Now the question is, for regular users, do they ever need more than sixteen billion, signatures for a single public key? If we, if we buy that assumption, then we can reduce the size, from eight thousand bytes to three thousand bytes, four thousand bytes in, in that range. So that is one of the, the things, where we applied this specific, Bitcoin domain to the question of, how to optimize this, these signature schemes. And I think the other big thing that we did is we looked at, so research in the post-quantum space isn't, standing still. So there are, new optimizations even for those hash, 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 ten, twenty percent sometimes in terms of, of, of size compared to the already standardized, hash-based signatures." }, { "speaker": "jonas_nick", "time": "23:30", "start": 1409.67, "text": "I see. And just to be clear, what you're talking about there with the eight thousand bytes, that's Sphinx Plus, yeah?" }, { "speaker": "stephan", "time": "23:35", "start": 1414.75, "text": "Yes." }, { "speaker": "jonas_nick", "time": "23:36", "start": 1415.93, "text": "And then" }, { "speaker": "stephan", "time": "23:37", "start": 1416.53, "text": "called Sphinx Plus, yeah." }, { "speaker": "jonas_nick", "time": "23:38", "start": 1417.83, "text": "And then this other type I've seen, called Shrieks. Can you talk to us a little bit about Shrieks? Yeah." }, { "speaker": "stephan", "time": "23:44", "start": 1424.22, "text": "So Shrieks is, I mean, it's a relatively straightforward idea. I'm not sure if we're the first one who, 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, how hash-based signatures work, and for that, I first need to explain the, the concept of a, one-time signature scheme. So one time signature scheme," }, { "speaker": "stephan", "time": "24:13", "start": 1452.65, "text": "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, 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, a list, a long list of many, one-time signature schemes, and, then, in the-- When you s-s-the first signature you produce, you use the first public key from the first one- One time signature scheme. Then you use the second public key, then the third, and so on. so, this is, essentially how a scheme work-- 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. But, what you see is, when, when I say the first, you, 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. The premise is" }, { "speaker": "jonas_nick", "time": "25:52", "start": 1551.6, "text": "we don't want to re-sign again with that same key. Yes. Right? And that is this-- So just from your paper, xMSS, Extended Merkle Signature Scheme, just for the, thing. But I guess what you're getting at is this idea of Every Bitcoin, you know, 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 complicate-complicate-complicated when we're talking about, oh, I've already signed up to seven thousand nine hundred and eighty-seven, sign with seven thousand nine hundred and eighty-eight," }, { "speaker": "stephan", "time": "26:29", "start": 1589.14, "text": "like, and more complicated examples, right? And that, that, I think that wouldn't be 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, produce transactions, sign or whatever, and then your computer, crashes, breaks down, you need to restore your backup, and then you're reusing the old backup now you could" }, { "speaker": "jonas_nick", "time": "26:55", "start": 1614.9, "text": "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 re-si-s-sign with an old state, you know, it's kind of sort of maybe loosely analogous there. yeah, it's, I think it's pretty similar, yeah. Yeah. And so as I'm understanding, the idea of Shrink is like, it's, you're doing like a hybrid. It's like, in the happy path or the good case, you're doing stateful, and then you're having like a stateless backup, but the" }, { "speaker": "stephan", "time": "27:26", "start": 1645.7, "text": "Yes, that, that is right. But first, I have to say, so these one-time signatures, they are, relatively small, so they are just two hundred and fifty bytes, a single one of, of them. Okay. but, like We probably, since w- 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-f-so far in the explanation is that you built this, Merkle tree of public keys And now anytime you want to sign for one of the Leafs of this tree, you not only need to produce the signature, but you also need to produce a, a Merkle proof to show that this public key is included in the, in the Merkle tree." }, { "speaker": "jonas_nick", "time": "28:27", "start": 1707.09, "text": "Okay, so that's also expanding the size of the transaction then?" }, { "speaker": "stephan", "time": "28:30", "start": 1710.11, "text": "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 it. 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, the, the one-time signature is pretty small, two hundred seventy bytes something. so that's what we use for the stateful part. Okay, so we could deploy that, but that has, still has the problem that, you cannot at all produce a backup that would always be insecure, because, or no, no static backup, I should say, right? So you- Right now, like we do backups, we write down, words on, on a piece of paper. That wouldn't be possible anymore because anytime you would, you would make a signature, you would have to update your piece of paper and at the counter to, to, to the paper. So that's, that's, impractical. So what we can do then, and that is Shriks, we combine the stateful scheme, which is very efficient, o-in the stateless scheme. meaning that on the device where we have the state, we can use this optimized stateful signature scheme, but on a device where the seed has been imported that doesn't know the state, we would use the stateful scheme. So the stateful scheme is more, costly, it's larger size Size is 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, are very small. So that is, that shrinks essentially. Big question is, even, even if we have the setup, our devices capable of holding state, securely i-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, 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, to a file, as I said, the wallet file just doesn't work because users will, will back it up" }, { "speaker": "jonas_nick", "time": "31:06", "start": 1866.21, "text": "or-- 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." }, { "speaker": "stephan", "time": "31:27", "start": 1887.32, "text": "Yeah. Right. So, in this entire space of, of trade-offs, Shrink's, is very optimal in terms of cost, but it ha-- in terms of co-- sign, signature size, verification cost, signing cost But, you have this, statefulness problem" }, { "speaker": "jonas_nick", "time": "31:47", "start": 1907.17, "text": "to deal with, okay. And so it would be like a new paradigm that people would have to manage, and maybe, maybe in certain contexts it could be managed, like maybe if it's like an always-on lightning node or something like that, maybe it's, you know, maybe that, in that context, it might make sense, but then for like the deep cold multisig sort of thing, then maybe you need like the stateless backup in that case. And then The, the other aspect of it is, would we still have access to things like threshold multisig, right? So two of three, three of five, like we would still have that?" }, { "speaker": "stephan", "time": "32:22", "start": 1941.87, "text": "Yeah, so that, that was another question that we had, when we started this paper is, All these nice advanced, signature, or not sig- cryptographic schemes that we can use today from, well, we have, we have Taproot, we have, music multisignatures, frost threshold signatures, we have silent payments, And we have even like atomic submarine" }, { "speaker": "jonas_nick", "time": "32:47", "start": 1966.61, "text": "swaps" }, { "speaker": "stephan", "time": "32:47", "start": 1966.93, "text": "and" }, { "speaker": "jonas_nick", "time": "32:47", "start": 1967.03, "text": "atomic payments, like atomic, swaps. Adapter" }, { "speaker": "stephan", "time": "32:49", "start": 1969.34, "text": "signatures, yeah. Adapter signatures will be one. So can we- So these" }, { "speaker": "jonas_nick", "time": "32:54", "start": 1973.84, "text": "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, lattice-based signatures is it different or-" }, { "speaker": "stephan", "time": "33:04", "start": 1984.47, "text": "Yeah. So in lattice-based signatures, i-i-it's different. So in hash, in, in-- So that was one of the results also for me because I thought, \"Oh, maybe there's thing here or there that we could do, that people in the academic community haven't looked at, because like few people look at what we, are interested in in, in Bitcoin.\" we found some tiny optimizations Probably not worth the implementation complexity, so I would say that, HD wallets, I have forgotten, HD wallets would also not, not really, work in the way they do. So, that would-- that doesn't work anymore, so that we lose some of the efficiency gains that we have. Ahead or that we have right now with, with class- with classical signature schemes. In the lattice world, since, lattice-- so hash, hashes, you can just imagine, they are these, garbling machines that, take the input and produce some like random-looking output. And lattice, lattices, lattice-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- We're, using today, and there, there exists somewhat equivalent things to, multi-signatures and threshold signatures. They also have downsides compared to, to what we have today. But right now at, Blockchain Research, we actually have a project looking into lattice-based, signatures. Are they practical for Bitcoin? And, can we-- Are these advanced constructions like, multi-signatures, threshold signatures, real-" }, { "speaker": "jonas_nick", "time": "34:45", "start": 2084.78, "text": "Really practical. Okay. Yeah. So I guess, maybe we'll have to, you know, 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, like, so let's say right now today, if I, you know, make a, a cold card and I, you know, or whatever, I, I make a, an output descriptor and have a watch-only wallet and have like the computer, able to generate new receiving addresses while keeping, let's say, the cold card or the hardware wallet somewhere else, we're, we're kind of losing a bit of that, Bits and pieces you can sort of, get. But yeah, as you said, a lot of the," }, { "speaker": "jonas_nick", "time": "35:36", "start": 2135.61, "text": "fancy crypto tricks that, you know, you and other guys have come up with, we, we'd lose some of those. So for example, even in the silent payments context, my understanding is At least today with sound 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 pawn you from a privacy perspective of knowing, \"Oh, hey, this is Jonas's silent payments address. I know he took all these payments because I recomputed that shared secret using, hypothetically, the quantum computer.\" that's, yeah. So these are things that are, I guess- Yeah, that is, that is" }, { "speaker": "stephan", "time": "36:18", "start": 2177.98, "text": "for sure, for, for sure, a, a problem that, so, so generally these types of attacks are called, I think store and decrypt later, store now, decrypt later. What you could also do is right now you store all the web traffic and then later you decrypt everything, that hasn't been moved to a post-quantum scheme and, and Bitcoin you can do exactly the same thing. Right. Because everything's on" }, { "speaker": "jonas_nick", "time": "36:42", "start": 2201.76, "text": "chain in Bitcoin, right? So it's all there anyway. So you don't need to" }, { "speaker": "stephan", "time": "36:44", "start": 2204.4, "text": "store it, it's on the chain, right? Yeah, right. and, like Bitcoin also uses, encryption on the peer-to-peer layer. to, protect against a global passive adversary that just listens to all, i- all connections, and that would also be affected by, by a quantum computer because it doesn't-- it uses the same, a, a very similar method to, to compute a shared secret that would also be, vulnerable to, to a quantum computer. So, an attacker that just stores all this, this data could also later decrypt it and maybe, make use" }, { "speaker": "jonas_nick", "time": "37:21", "start": 2241.01, "text": "of it. I see. Yeah. And so I guess this is kind of, there was like a, a point of contention in some of the online debates of saying, people saying, \"Oh, 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? Yeah. Yeah. but the, the-- but there is encryption at the P2P level, which is another, like, a separate thing we're talking about, right? Yeah. Yeah." }, { "speaker": "stephan", "time": "37:47", "start": 2266.67, "text": "Yeah. Yeah. There's also encryption on the Lightning Network, for example, that would be affected." }, { "speaker": "jonas_nick", "time": "37:51", "start": 2270.97, "text": "Right. Okay. Yeah. Well, there you go, that's another one. So I guess would-- in the hash-based world of, Is Lightning like fine? Like, can we still do Lightning, but just in a different way?" }, { "speaker": "stephan", "time": "38:08", "start": 2288.03, "text": "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, your, opening closing a channel will probably be more expensive, at least if you use hash-based signatures, but I don't see a reason why it wouldn't work in, in principle." }, { "speaker": "jonas_nick", "time": "38:41", "start": 2320.58, "text": "I see. and then, I was gonna say the, with the, so now one other thing that, like, as 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 dot exchange or people who are doing like on-chain to off-chain swapping, to-- the thing that makes that atomic isn't that the adapter signature? So I guess we would need some new form of that." }, { "speaker": "stephan", "time": "39:19", "start": 2359.08, "text": "I mean, swaps can still work. the adapter signatures are really just an optimization to, to swaps that we could use to make the classical swaps work. So we could" }, { "speaker": "jonas_nick", "time": "39:28", "start": 2368.35, "text": "do some other form of swapping. Yeah, the classical" }, { "speaker": "stephan", "time": "39:30", "start": 2370.35, "text": "swaps they actually just use a hash and a signature. And then the sort of advantage of adapter signatures was then or is that, you don't need these two-- you don't need an extra hash, which is, more efficient and also more private on chain. I see. Okay, so we don't lose like cross-chain" }, { "speaker": "jonas_nick", "time": "39:50", "start": 2389.8, "text": "swapping or atomic swapping per se, we would just have to like, it would be like a new thing." }, { "speaker": "stephan", "time": "39:55", "start": 2394.67, "text": "Since you brought up, HD, We don't lose the entirety of HD, so you-- 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, 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. Right. Or what's known" }, { "speaker": "jonas_nick", "time": "40:25", "start": 2424.59, "text": "colloquially as a watch-only wallet nowadays. Right. You, we would kind of- Kind of lose that aspect of it. Right. So," }, { "speaker": "stephan", "time": "40:30", "start": 2429.74, "text": "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, would" }, { "speaker": "jonas_nick", "time": "40:44", "start": 2444.03, "text": "have to watch those addresses now." }, { "speaker": "stephan", "time": "40:46", "start": 2446.21, "text": "But it's maybe at some point, the, it doesn't have enough addresses, or it's out of addresses to look for, so it needs to ask the hardware wallet to pre-generate. So we'd have to have a setup where" }, { "speaker": "jonas_nick", "time": "40:56", "start": 2456.07, "text": "like maybe, There's like a hundred addresses on your computer that you can watch, and then once you've, once you've hit your one hundred, 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 wallet to do the watch-only, right, right. But" }, { "speaker": "stephan", "time": "41:11", "start": 2471.02, "text": "I mean, addresses or public keys, they're pretty small, so it would be easy to use more than just a hundred. Okay. So it, it could be like thousands or something, yeah, yeah. I mean, you can store some, some megabytes of, of public keys, I guess, on your, on your software wallet without any issues. But I guess" }, { "speaker": "jonas_nick", "time": "41:27", "start": 2486.91, "text": "another obvious corollary is we're gonna need new hardware wallets, right? We're gonna need, 'cause a lot of hardware wallets now, for security reasons, are intentionally underpowered. And I think, you know, the, the, like some of the hardware wallet makers have said that the reason is for security purposes. So that's like another thing of In the post quantum world." }, { "speaker": "stephan", "time": "41:48", "start": 2508.39, "text": "Yeah, that is, that is another interesting dimension. So, so far we've only really talked about signature size, but really another aspect is, how long does it take computational capacity- How long does it take to produce, produce a signature? And, in, on regular hardware wallets, I 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 aren't smart cards, but low-powered CPUs It would take maybe two minutes to produce a single Sphinx plus signature. So that is, yeah, that's not great. Not great downside too," }, { "speaker": "jonas_nick", "time": "42:26", "start": 2546.1, "text": "yeah. But," }, { "speaker": "stephan", "time": "42:28", "start": 2547.82, "text": "but they can, they can deal with it, which I think is kind of, is, is good news. And I suppose Once, people actually want to produce those signatures, then hardware wallet manufacturers, they 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, those numbers down. So I think that is, a realistic possibility" }, { "speaker": "jonas_nick", "time": "43:01", "start": 2580.69, "text": "Yeah, interesting. Okay. The other aspect is, is," }, { "speaker": "stephan", "time": "43:03", "start": 2583.23, "text": "is verification time, right? 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 we want that, nodes shouldn't require-- running a node shouldn't require enormous resources for decentralization, et cetera. And those hash- Hash-based signatures, verifying a single hash-based, signature is more expensive than verifying the, the Schnorr signatures." }, { "speaker": "jonas_nick", "time": "43:39", "start": 2619.24, "text": "So in the Schnorr, let's say, paradigm Do you know like roughly how much? Is it like a five x more, ten x more? Like, do, do, can you have a rough idea?" }, { "speaker": "stephan", "time": "43:48", "start": 2628.42, "text": "Oh, I would think in the Shrink paradigm, if they use the optimized, the optimized path, so if you have the state, and everything, then, it should be pretty, the verification cost should be comparable to, to what we use today. Gotcha. Shouldn't be a big difference. If they have to use the stateful path, then, You think maybe, maybe fifty times more expensive? Fifty times. Yeah, but it's also, it's also much larger. So per byte, yeah, so it's also much larger. Okay, I get you, I get you. Because the cost is about the same." }, { "speaker": "jonas_nick", "time": "44:28", "start": 2668.47, "text": "Oh, I see, yeah, yeah. So because then like, if a typical Bitcoin block today- I don't know the ex- the average, but, you know, call it two megs or one point eight megs or something like that range. and then, I guess, I guess, I mean, while we're here, let's talk a bit about the block size aspect of this, because- Let-- okay, just for, for example's sake, let's say we go, we, 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, two hundred and seventy bytes or something? Yep. In the best case. So we're talking like maybe five or six x what a current signature size is?" }, { "speaker": "stephan", "time": "45:04", "start": 2703.76, "text": "Yes, so 64 times, 64 bytes is the current signature size, yeah, it would be, four to five times." }, { "speaker": "jonas_nick", "time": "45:11", "start": 2711.14, "text": "Yeah, okay, so let's say like five x. Does that mean, kind of loosely speaking- Where taking, if we keep the block size the same, like four million weight units, etcetera, does that mean we're gonna have like approximately one fifth the capacity for transactions, like loosely?" }, { "speaker": "stephan", "time": "45:31", "start": 2730.61, "text": "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 pa-pa-part, so I would expect that. But it's the signature is one of the bigger" }, { "speaker": "jonas_nick", "time": "45:41", "start": 2741.4, "text": "parts of the transaction, right?" }, { "speaker": "stephan", "time": "45:43", "start": 2742.64, "text": "Yeah, it would become the big-- Well, we have these transac- Action outputs, they, they are large, inputs referencing previous outputs, so they are all pretty large and they aren't affected by the, the witness discount. So I, I haven't run the numbers, it should be pretty easy to, to run the numbers, but it would be I think we would be able to support between a half of the tran-- fifty percent of the transactions that we have right now and hundred percent somewhere in that range. Okay, so it's not like a" }, { "speaker": "jonas_nick", "time": "46:11", "start": 2770.59, "text": "crazy downgrade, but, you know, it's gonna-- and, 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?" }, { "speaker": "stephan", "time": "46:28", "start": 2787.57, "text": "Yes, yeah, yeah, that is correct." }, { "speaker": "jonas_nick", "time": "46:30", "start": 2789.55, "text": "Because those stateless ones are much big, as you said, they're like eight kilobytes or something like that, right?" }, { "speaker": "stephan", "time": "46:35", "start": 2794.78, "text": "Yeah, four kiloby- 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 too, to what we have to- Oh, okay." }, { "speaker": "jonas_nick", "time": "46:50", "start": 2809.99, "text": "So that could be, yeah. And so I guess that's the other thing the community obviously, that was very controversial in the twenty fifteen to twenty seventeen era, the block size wars. Do you think the community should reopen that conversation around quantum and say, \"Well, if we're gonna 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, eight million weight units or what? What do you like, do you think that is?\" I guess, obviously, I understand this could be a controversial thing, but do you think it is worthwhile to talk about?" }, { "speaker": "stephan", "time": "47:25", "start": 2845.16, "text": "I, yeah, for sure, I think it's worth, worthwhile to, to talk about. I mean, the environment is always changing that Bitcoin operates in. There's, and therefore Bitcoin must adapt in any way, anyway. the question is, what is the risk of trying to find consensus on a, on a new block size, and can that even- Be done, I think it can, maybe with, with some arguments, but yeah, I think we should, it makes sense to, to talk about it. But in terms of exact sizes or, or something, I think that's way, way too early right now." }, { "speaker": "jonas_nick", "time": "48:01", "start": 2881.0, "text": "I see. Yeah. But, yeah, I mean, just Do you, I 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, like 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, like there was, you know, in those first few years of ASICs, there was like a pretty, you know, pretty big, improvement, and then after a while, like the im-pro- the improvements slowed down a bit. Do you have a sense of what that is in quantum, post-quantum crypto for Bitcoin?" }, { "speaker": "stephan", "time": "48:45", "start": 2924.8, "text": "It's almost as hard as giving an estimate for a quantum computer, right? These timelines for technology are, are just, are just difficult. I don't really expect a breakthrough in, hash-based signatures. Let's base 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. I would expect there's, there's something there. For example, signature aggregation, which is a super interesting topic. Now, right now, we've only talked about, right? 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, in the transaction. So using Bitcoin different than, than we do today. That, that would be an option Option if this aggregate signature in the end would be much smaller than the sum of the, 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, to be, explored. And then maybe if we only have a signature per transaction that is relatively Relatively large, but somehow we're able to all kind of amortizing" }, { "speaker": "jonas_nick", "time": "50:29", "start": 3028.94, "text": "it across a lot of transac-a lot of inputs going into that transaction, let's say." }, { "speaker": "stephan", "time": "50:34", "start": 3033.53, "text": "Produce transactions collaboratively, then maybe that would also get rid of, of some of those problems with the, with the large signatures. And also, And in, and one a- 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, 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 taproot. There could be like" }, { "speaker": "jonas_nick", "time": "51:12", "start": 3071.5, "text": "fingerprinting based on which one you use." }, { "speaker": "stephan", "time": "51:14", "start": 3073.84, "text": "Yeah. So another possibility in this big space of," }, { "speaker": "jonas_nick", "time": "51:18", "start": 3077.9, "text": "of options. 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 wanna call us, whatever you, 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 it's sort of like, what is the minimum viable thing that we can all agree on and say, \"Yeah, that's the path forward.\"" }, { "speaker": "stephan", "time": "51:44", "start": 3104.22, "text": "yeah, right. I mean, that is, i-- 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, or whatever, and that's better than having, nothing, which I think is possible in an emergency situation. In emergency tomorrow, and I think it wouldn't be that hard to get, consensus on it if there was a real risk, although it's always hard to, to estimate what, what, what the risk is. But yeah, in, in-- I think that will be a huge challenge potentially to, to agree on, on one of, of those schemes, just because the, the space of, of, of options is just, is just enormous. And, all of them affect, affect Bitcoin users in one way or" }, { "speaker": "jonas_nick", "time": "52:32", "start": 3152.01, "text": "another. 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 say it like, \"Well, we're still limited, 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, 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 va-validate, and then that became like, \"Is that a DOS vector?\" You know?" }, { "speaker": "stephan", "time": "53:14", "start": 3193.83, "text": "I mean, I don't really think that would be the case for, for these kinds of, 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, as a new, as a new signature scheme. So one of the advantages of, of using a standardized scheme, for, for example, is that, Good implementations already exist. they haven't been written for a consensus system like Bitcoin, which is its own, own challenge, but they have been very well written and they, they are being used in, in production So in principle, it wouldn't be unthinkable to just pick, pick one of them. And when I say they ha-- they aren't optimized for, for, consensus system is that, in, in 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, new versions. So a signature that is valid with one version shouldn't be, become invalid with, with the next- Next version, or even worse, the other way around, the signature was invalid, would become valid. Usually, that's not such a big deal if you're just signing software or use it for the web, but 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, schemes" }, { "speaker": "jonas_nick", "time": "54:57", "start": 3296.98, "text": "to Bitcoin. Yeah. So summarizing then, Shrink, sorry, 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, in Bitcoin transaction land. but the, let's say, Bitcoin optimized version that you and others are working on is shrinks. And what would be required for that to become, you know, like, does it just need like more review and research to, for people to sort of come together and agree, okay Hey, we think Shrink is, a good bit-- Bitcoin optimized form of Sphinx Plus or what?" }, { "speaker": "stephan", "time": "55:39", "start": 3338.95, "text": "Yeah, so, I, I wouldn't say that Shrink is our, our main proposal. I mean, in the, in the paper what we're doing, we're looking mainly at, 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, and signing time." }, { "speaker": "jonas_nick", "time": "56:04", "start": 3364.43, "text": "I see." }, { "speaker": "stephan", "time": "56:06", "start": 3365.61, "text": "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, with hardware wallets? Although I, I think that it's not such a big deal right now, because in the future we could have, hardware acceleration for doing, fast, fast hashes. In terms of Frinx, the question is, I think, hardware wallet many- Manufacturers, do they think they can keep state securely? So that, that would be an, an interesting, sort of, sort of input that we're, we're looking for." }, { "speaker": "jonas_nick", "time": "56:42", "start": 3402.35, "text": "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, I don't know, but maybe that's like a more of a 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? Yeah. Nevertheless." }, { "speaker": "stephan", "time": "57:22", "start": 3441.72, "text": "But one of the major, pushbacks that we got for this, 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, your own thing for, for Bitcoin? And the answer to that, I think, is just that, I think the, the limited resource is really the, the, resources, the verification resources that we h-- and network bandwidth that we have on our nodes. And if we can reduce the signature size by, fifty percent, I think that's pretty significant. And I hope the limit isn't, designing, the, secure libraries and writing standards. Sure, that is very resource intensive, but I feel like the sort of Resources on the nodes are the more, significant limit than our manpower to solve these problems and write, write good code." }, { "speaker": "jonas_nick", "time": "58:32", "start": 3511.94, "text": "I see, yeah. And a-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, like from, you know, can you give people a sense of like transactions today are more like a few hundred bytes, right? Yeah. 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 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 five x or a ten x block size increase." }, { "speaker": "stephan", "time": "59:09", "start": 3549.04, "text": "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 range. So Shring, if statefulness works, is actually the smallest, post-quantum, signature scheme outside of like, schemes that rely on, rather, yeah, yeah. More, more crazy mathematical assumptions." }, { "speaker": "jonas_nick", "time": "59:36", "start": 3575.83, "text": "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 or 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 Script path, but this might enable like a, a gradual transition. I don't know, do you have any thoughts to share on that transition aspect? Yeah," }, { "speaker": "stephan", "time": "01:00:40", "start": 3640.87, "text": "so yeah, right, so there's, Pip 360. And PipFrix 360 has evolved quite a lot, since, it was, first proposed. And, 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 wanna spend, you need to, reveal one of those, leaves. In this Merkle root, which, then, show-- gives you the spending conditions, and then you need to provide a signature for that. Bib360 by alone, by itself, doesn't provide, quantum security, only against, long, exposure attacks, because it doesn't propose a post-quantum signature scheme." }, { "speaker": "stephan", "time": "01:01:40", "start": 3700.57, "text": "so that is, that is one possibility. The downside of that is that if people would move to Bitcoin 3.60, then they would lose all of the performance gains that we got with, Taproot in, in the first place essentially. Not all of them still have the Merkle tree, but, you couldn't do any like, the, the key, key spend path was just more efficient than, using the Merkle tree to spend, and you had, Music, frost, et cetera." }, { "speaker": "jonas_nick", "time": "01:02:09", "start": 3729.64, "text": "We would lose all that directly" }, { "speaker": "stephan", "time": "01:02:10", "start": 3730.68, "text": "on the key spend path, so we lose, that. But it's, it's a possibility. 360 isn't complete, as I said, but, sure that, that is a possibility. And another possibility is, is what you mentioned, this, idea popularized by, by Matt Corell, unfortunately doesn't have a snappy name or bip associated with it, so I, I'm struggling to find, find a good name for it, but, I think it A viable approach, where, you just use Taproot as, 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, using a script path. And though, 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, until Q day comes." }, { "speaker": "jonas_nick", "time": "01:03:32", "start": 3812.03, "text": "I see, yeah. So I guess there's different options on exactly how, you know, the community- goes about this upgrade," }, { "speaker": "jonas_nick", "time": "01:03:42", "start": 3822.27, "text": "so, yeah, coming back to what we were saying before, it's gonna 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, if I'm getting this wrong, but as an example, one way could be maybe if Bit360 was sort of paired with like one of these schemes, whether it's Sphinx Plus or Shrieks 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 Bit360 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, the vulnerable coins per se. Maybe it's not, really accurate or precise to just say, \"Oh, yeah, Satoshi's coins,\" but the quantum vulnerable coins might end up getting burned or frozen in some way," }, { "speaker": "jonas_nick", "time": "01:04:40", "start": 3880.67, "text": "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 the, on those vulnerable coins.\" yeah, I think that will actually" }, { "speaker": "stephan", "time": "01:04:52", "start": 3892.5, "text": "be the, the much, bigger discussion that might have quite an impact on, on the Bitcoin space. Even lead to a split." }, { "speaker": "jonas_nick", "time": "01:05:02", "start": 3902.94, "text": "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 SegWit 2x and block size wars, you-- like in the SegWit 2x 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 wanna 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. Or it can become" }, { "speaker": "stephan", "time": "01:05:51", "start": 3951.27, "text": "permanent." }, { "speaker": "jonas_nick", "time": "01:05:53", "start": 3953.05, "text": "Yeah. Or just like a permanent chain fork split and, you know, like B Cash 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?" }, { "speaker": "stephan", "time": "01:06:06", "start": 3966.25, "text": "Yeah." }, { "speaker": "jonas_nick", "time": "01:06:07", "start": 3967.47, "text": "I," }, { "speaker": "stephan", "time": "01:06:07", "start": 3967.65, "text": "I guess so too." }, { "speaker": "jonas_nick", "time": "01:06:09", "start": 3969.59, "text": "Yeah. anything else on like transition aspects? I mean, what about the time? Like, people have tried to estimate, okay, is it gonna 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 quan-quantum resistant or quantum secure scheme, that, that itself could take time depending on if we have a block size increase or not or whatever, or the size of the scheme, the new scheme." }, { "speaker": "stephan", "time": "01:06:41", "start": 4001.12, "text": "That's actually a good question. I, I haven't run the numbers on that. I don't know. But that's a good question. Like, the minimum of time you need, assuming everyone would, would migrate, or at least most of them, right? And is it gonna be" }, { "speaker": "jonas_nick", "time": "01:06:54", "start": 4014.53, "text": "like chaos and cacophony of like, some people are like putting through transactions at like crazy high 'cause they wanna get through first and make sure their stuff is safe. I mean, who knows what could happen there? yeah, so that, that is" }, { "speaker": "stephan", "time": "01:07:05", "start": 4025.09, "text": "one of the advantages of the," }, { "speaker": "stephan", "time": "01:07:10", "start": 4030.74, "text": "Just that you could start to use this to-- It's a gradual transition, yeah. Just add an additional, Merkle, Merkle path to your, to your tap, taproot tree, with a post-quantum signature scheme, okay, assuming this was deployed, and then you can use, your y- Your wallet as normal today, until" }, { "speaker": "jonas_nick", "time": "01:07:33", "start": 4053.97, "text": "hypothetical Q day, and you, you, you kind of burn the key path." }, { "speaker": "stephan", "time": "01:07:38", "start": 4058.19, "text": "So that would be a pretty gradual approach." }, { "speaker": "jonas_nick", "time": "01:07:41", "start": 4061.49, "text": "Yeah. But of course, we never know how" }, { "speaker": "stephan", "time": "01:07:43", "start": 4063.27, "text": "many people have actually migrated in, in that. Yeah." }, { "speaker": "jonas_nick", "time": "01:07:47", "start": 4067.04, "text": "And then that's the other problem as well of like- Today, there are millions of coins vulnerable, and you-- I guess obviously step one is, hey, 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 a gra- if it's like a sudden thing or it's a gradual break, in the quantum, like in terms of quantum computing coming, because if it's a gradual thing, then you would expect over time that six million coins that's currently vulnerable, a lot of those people will, 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 the other co- 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, \"Oh, Satoshi has a million coins.\" Really what that is, is this quote-unquote \"Patochi\" mining pattern, and they're, they're stored in lots of, many, many, many outputs. So it's not that the quantum computer is just gonna do like one round of hacking and just get like a million coins. It's like they would have to go through each of those. The bigger juicy targets would be the cust" }, { "speaker": "jonas_nick", "time": "01:09:02", "start": 4142.27, "text": "that would be the real juicy target for a quantum hacker per se." }, { "speaker": "stephan", "time": "01:09:06", "start": 4146.31, "text": "Right. So, yeah, and I think this view that, quantum computer comes gradually or, or, at one point of 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 Eleven has, has written about. It's, it's pretty interesting, but it seems to be more realistic to me that we will have a lot of uncertainty Uncertainty and it will be very messy, in quantum computers, and there might even be also a lot of, of, of fud and people can, can fi-financially take advantage by using that fud and claiming they have- Broken, Bitcoin public key or something like that, but they haven't, but they can fake it con, con, convincingly. so yeah, 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, regarding the switch to post quantum stuff" }, { "speaker": "jonas_nick", "time": "01:10:11", "start": 4211.89, "text": "Yeah, so it's, it's gonna 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, you know, maybe, maybe that ends up being like, okay.\" Pip360 and some particular scheme, whether it's Sphinx Plus or Shrieks Plus, and just let the chips fall where they may, right? Like it's your responsibility, okay? It's like, \"Here, 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 gonna do a block size increase for that, like to compensate for the loss of transactional capacity? Don't" }, { "speaker": "stephan", "time": "01:11:06", "start": 4266.5, "text": "know. Or our, layer twos, and rollups and ARCs are good enough to just deal with this. Right, to just take fifty percent" }, { "speaker": "jonas_nick", "time": "01:11:17", "start": 4277.27, "text": "less transactional capacity or even less or something. Yeah." }, { "speaker": "stephan", "time": "01:11:21", "start": 4281.97, "text": "Yeah, so lot, lot of hypotheticals, really hard to project this into the future. Yeah." }, { "speaker": "jonas_nick", "time": "01:11:27", "start": 4287.34, "text": "Yeah. Okay, fair enough. but, at least, you, 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, anything else you think we didn't cover that you, you know, you think, you really think we should talk about?" }, { "speaker": "stephan", "time": "01:11:44", "start": 4304.11, "text": "I think we covered pretty much, everything. So if you wanna leave, wanna re The paper," }, { "speaker": "stephan", "time": "01:11:54", "start": 4314.65, "text": "I'm wondering where to best, best find it, find it. oh, I'll put the links" }, { "speaker": "jonas_nick", "time": "01:11:58", "start": 4318.34, "text": "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, Nickler, right? N1c k l e r, just off the top of my head, I think that's the one. So, yeah, of course, guys, follow Jonas. keep up to" }, { "speaker": "jonas_nick", "time": "01:12:21", "start": 4341.15, "text": "Thank you very much for, coming on the show and helping, keep us update, keep us, educated on this. Thank you." }, { "speaker": "stephan", "time": "01:12:28", "start": 4348.26, "text": "Yeah, awesome. Thank you." } ] }