An Explanation of Post-Quantum Signature Schemes | Bitcoin 2026

Quantum, quantum, quantum, quantum. Who's Who's ready? So, there's a there's a few different sessions in this event talking about quantum. Um this session in particular is going to talk about post-quantum signature schemes, which is a component of that, and we may touch on some other pieces of the quantum discussion as necessary, but we're going to try to to scope it to that limited scope. Um so, maybe we can run through introductions really quickly. I'm Mike Schmidt, executive director at Brink, and I'm contributor at Bitcoin Optech, and I'm joined by some esteemed panelists here, and I'll let them introduce themselves briefly. I am Jonas Nick, director of research at Blockstream. I've been working on the intersection of cryptography and Bitcoin full-time since 2017. Uh hi, I'm Tadge Dryja. I worked on Lightning Network, discrete log contracts, UTXO, and I've now sort of gotten nerd sniped into a lot of the post-quantum stuff. Uh hi, I'm Kandui Vision. I'm an independent cryptographic engineer and researcher. Lately, my research has shifted towards post-quantum crypto, especially in hash-based and isogeny-based signature schemes. Awesome. Thank you all for joining. Um maybe to frame the the problem um to get everybody into the funnel of this discussion. So, Bitcoin is secured by your coins being in a UTXO and you being able to provide a signature for a public key that authorizes the spend of those coins. Um the problem is with a cryptographically relevant quantum computer, those same signatures could potentially be forged in the the way that the signatures are done today, and so we need to explore the idea of post-quantum signature schemes. Um maybe an initial reaction to folks is could Bitcoin ever add a new signature scheme? And um and the fact is Bitcoin already has, right? There was an opportunistic addition of Schnorr signatures several years ago, um and this was the Bitcoin community making a positive decision. Um hey, we have the opportunity to add a new signature scheme that will give us some linear properties that could be valuable in enable things like MuSig two and Frost threshold signatures. Whereas, with quantum, when we're exploring quantum signatures, um maybe it could be viewed as somewhat of a negative decision, where we're not we're not deciding what great features we're going to add, but what could we possibly retain from from what we have in Bitcoin today in a new signature scheme, with the obvious upside being that that the signature scheme would be quantum resistant, right? And so, we're going to talk about a bunch of different approaches to that. Um maybe where we can start is Bitcoin isn't the only piece of software or protocol that needs post-quantum. You have things in the US like NIST that standardizes these sorts of uh signature schemes, and maybe we'll start with you, Tadge, on this one, and we can go around, but why can't we just pull a NIST post-quantum scheme off the shelf? What What may be some some considerations that we have there, um other than the fact that the NSA has backdoored NIST cryptography and paid $10 million to private companies to make it the default? Other than that, what might be some reasons that we wouldn't want to use NIST cryptography off the shelf? I can Well, maybe I There's the lattice expert and hash-based expert, um but I can sort of say that the general idea is like, yeah, we're Bitcoin's a little weird, and like, if you look at like the rest of the world is like X.509 stuff and RSA, and and Bitcoin uses its own curve and its own sort of system. Um that feels like it'll be the case with any kind of post-quantum stuff as well, where I think one of the big reasons almost all the other work is focused on lattice stuff. Um is because while the rest of the world, like, I'm saying mostly like web browsers, right? Web browser needs to connect to a website, they need to establish who they are and stuff like that. Um the big thing they want there is Diffie-Hellman. Well, you don't have Diffie-Hellman, but you want something equivalent. You want some way to have a shared secret and authentication. Um and lattices just give you that, right? Whereas, hash-based signatures don't, so I think that's one of the reasons there's much less interest in hash-based hash-based signatures in like the rest of the web ecosystem. It's cuz it's like, okay, it's a signature, but we want signatures and these other things, and we can get that with lattices, and we can't really I mean, maybe there's ways, but we don't have great ways to do that with hashes. Whereas, in Bitcoin, we we don't need I I can say we we don't do Diffie-Hellman in Bitcoin, but now we do because of silent payments. Um so, it's kind of funny that like, right as we're starting to do Diffie-Hellman in Bitcoin, it maybe is, you know, something we can't do as much. Um but in Bitcoin, we really only need signatures. Um and so, that's like why I think hash-based is a great focus. Jonas, do you have any comments on web post-quantum versus what Bitcoin could need? Yeah, I think one um sort of bad argument for not adding post-quantum to to Bitcoin is that uh well, the entire world is affected, and Bitcoin would be the least of your problems because the banks are affected and whatnot. I think that's a bad argument because um the world is at the moment transitioning to post uh quantum signature schemes, and they are using these uh standardized schemes that people have spent quite a while looking into, and they have I would say decent implementations. Um but uh these signature schemes, they were standardized for different purposes, as uh Tadge mentioned, um for like the web or for signing software, but not for signing um transactions, which is what we mostly care about in in Bitcoin. So, the question is then, given that these standardized schemes exist, and there is of course a lot of bigger um corpus of of academic literature, can we adapt those schemes to the Bitcoin use case? And how would that look like? Because the way we use uh signatures in Bitcoin is quite particular and different from uh what you need when you sign software or certificates. Kandui Vision, do you have a take? Uh yeah, I just like to mention that NIST has only standardized two signature schemes so far, ML-DSA and SLH-DSA. And there's another one coming on the horizon in the near term, but the thing is, the post-quantum signature zoo of different technologies available is very diverse, and there's a very large trade-off space available to us. And those NIST-standardized uh those NIST-standardized crypto systems, they only prescribe a certain set of trade-offs. And Bitcoin is a very niche demand for uh cryptographic tools. And I think that uh given there's a vast trade-off space we can explore, it makes sense to research what's possible and not try to restrict ourselves to just a a small subset of basically two or three signature schemes. So, you you mentioned the post-quantum zoo, or or maybe a way to think about it is like a a taxonomy. Like, what are the types of thing You guys have dropped some of these uh in in your initial answer, but maybe it would be worth it to explain to to the audience like, what are the kinds of these thing Like, what is lattice? What is hash-based? What is you know, maybe we can go through that at a high level, and then we can get into some of the trade-offs. Well, I don't think I could ever cite by memory all of the different genres of uh PQC signature schemes, but I can have a go at a few. Um there is of course hash-based signatures, which we've been talking about before. They are very conservative. Um they're very quick to verify. Signatures tend to be very large unless you use statefulness. And uh they are generally very expensive to sign for. Then there is lattice-based signatures. Uh these are a little newer than hash-based signatures. They use a newer set of cryptographic assumptions, um but they're very fast. They're very quick to verify and to sign, but the signatures are pretty pretty large. Um then there is isogeny-based signatures. Isogeny-based signatures are very compact, only about two and a half times larger than what we have today with uh elliptic curve Schnorr signatures. Um but they're very very slow to verify, uh about 100 times slower than Schnorr signatures. Now, that's being worked on, but um it's still a a pretty hard pill to swallow if you're trying to fill a block with these signatures. And there are other scheme genres, too. There's multivariate, there's code-based. Uh my memory fails me af- after that. Uh but there's a very big, diverse uh set of options available to us. And NIST is working on standardizing more of these signature schemes. And just to to emphasize the the important of the of the trade-off space, there's also this myth that um Bitcoin developers don't care about this, which is why they haven't done an upgrade yet, and they would have been able to do that already a while ago. I mean, these schemes have been um standardized, I think, since since 2024. But the problem really is that there is no drop-in solution for what we have right now. So, just to give you an idea, Conduition mentioned the the two standardized signature schemes. So, right now if everyone would use Taproot, uh we would have about 6.5 transactions per second. And this is limited by the block size and the block being found every 10 minutes. 6.5 transactions per second. If uh we would just adopt one of those standardized schemes, it would be 0.5 transactions per second or lower. So, this would significantly change Bitcoin. And not only does this make transactions more expensive um cuz signatures are larger now, larger fee, uh but also it essentially means that fewer transactions can be made, and this reduces the the usefulness of of Bitcoin. So, if we choose a post-quantum signature scheme, then we will have to live with those tradeoffs, at least once a quantum computer appears. And that's why it makes sense to explore this space of um of tradeoffs very thoroughly. If I can shill hash-based again and maybe shill Jonas cuz you haven't mentioned this, but another advantage to keeping researching it and not rushing into putting something in is like the standardized hash-based signatures are like 8 kilobytes, and just in the last, you know, year, it's like, "Oh, you have a paper." It's like, "Oh, it's 300 something bytes." There's ways to do it. You know, like there's a there's a lot of knobs to turn. And and those and it's not like, okay, it's cuz obviously smart people working on it, but it's not like all the NIST people and all these researchers at universities have not looked at the It's not like they're they're dumb and they just made a thing that's 8 kilobytes. It's like they have different goals, right? They're they're trying to make something that work like it's a standardization, so they're trying to make something that works for everything. So, they're like, "Okay, it can sign two to the 64 times." I don't even truly It's like an unpronounceable number of times. It's like, "We want to make something for them, NIST or whoever. They want to make something that is like very hard to use the wrong way, very like no foot guns, works for everything. And if that means it's 10 or 100 times larger or slower, okay, that's just what it is, right? Well, well, your browser will go a little slower or something." That's We can make different tradeoffs in Bitcoin. And so, that's that's why I think it's like Bitcoin-specific research is finding all these amazing, like, "Oh, wow, we can do much better." Um and it's not like we're way smarter. It's like we have a different goal. I want to draw back on something you said there, Taj, because uh some of the people in this room might not be that familiar with hash-based signatures, and the idea of a signature budget may be new to some people. So, maybe we should talk about that for a sec. Oh, in terms of statefulness or in terms of >> Or stateless, because there is no such thing as a fully stateless hash-based signature scheme. Yeah, so that that is another not great part where with elliptic curve signatures right now, you shouldn't reuse addresses, right? And everyone has been saying don't do that for 15 years, and people still do. But it's secure in that like if you receive coins, you post an address and you receive hundreds of different transactions, and you spend them all at different times, it works, right? The elliptic curve stuff works. It's not insecure to keep signing with the same key. With hash-based signatures, you need to sort of make it You I mean, you would explain this better. There are there are tradeoffs in how you do that, right? So, any hash-based signature scheme has this parameter, which is the what you could call a signature budget. And that determines how many signatures you can make with a single public key. Right? That could be just one, so you're just able to produce one signature, um which would result in a very small signature. Um so, that seems to be attractive, but it's not realistic because in Bitcoin even though if we don't reuse addresses, ideally we don't, although the receiver cannot really control that, we would still need to make multiple transactions, for example, if we need to bump the fees or in payment channels, um Lightning Network, etc. So, there is this signature budget parameter that is two to the 64 in this NIST standardized hash-based signature scheme. And we can go lower than that, and thereby reduce the size of the signature. We can still keep it enormous, like two to the 40 or something, which is about a trillion, and it would take hundreds of years to fill the fill the blockchain with trillions of signatures. Um or we can go even lower, and this is one of the parameters that we can tweak um when we look at the Bitcoin application. Well, it sounds like hash-based signatures don't add any new cryptographic assumptions. It sounds like we can tweak the parameters and get a smaller signature. Um so, is that it? What are the drawbacks to hash-based? There I mean, I would say the other things are more powerful, but I Okay, before people shill the other things, which are very cool and like you could probably make hash-based signatures out of like MD5, right? I I guess an analogy would be like it's a balsa wood uh bunker, where if the balsa wood turns out to be titanium, great, right? But just the structure of how these things are built, there's they're relying on very conservative, like very weak assumptions that like one-way functions exist, right? It's it's a little more than that, but but you're relying on something where if hash-based signatures break, I don't see how Bitcoin could exist, right? Bitcoin is already relying on more powerful assumptions for for hash functions than hash-based signatures do. Versus, you know, there are other all these other assumptions with lattices and isogenies and elliptic curves where, you know, we don't have any proof that they're secure. It could break. It could break without a quantum computer. Like maybe I mean, that would be really bad, but maybe someday someone researching quantum computers is like, "Wait, do I really need a quantum computer to do Shor's algorithm?" and figures out some way to do it on your laptop. And then then we really need this stuff. Um but I think to me, that's even if we do have other types that do have advantages, um having a hash-based signature is kind of nice because you kind of know that like it's the last thing to break. Would you kind of agree in that? Yeah. Yeah, for for sure. I mean, I think the best argument is that we already use this assumption in Bitcoin. If that breaks, then the blockchain breaks, right? Because we use SHA-256 to refer to the previous block. We use SHA-256 to commit to transactions, um etc. Well, you've been working for years or your your team at Blockstream, among others, on interesting things that we can do with Schnorr, that you we can have threshold signatures that look like one signature on chain. You can do MuSig and multiple signatures rolling into one. We got silent payments, all these interesting things. How many of those can we port over in a hash-based world or or then maybe we can talk on some of the other approaches. Basically none of them. Uh unless you use some very heavy machinery, like multi-party computation, but you know, realistically with uh minimal assumptions, not that many. Uh there's some mitigations to that. I sent up a post in the mailing list before of how you can create this like drop-in replacement for BIP32, but it requires using a static hash-based key. So, you would have uh an xpub, like a BIP32 xpub, which embeds a hash-based public key. And then anybody who derives addresses from that xpub would just have to inherit that hash-based static key. Um and you can create hybrid addresses from this. So, you can use Schnorr signatures, and every address would be unique that you derive from this xpub. But ultimately, if you needed to spend a hash-based uh path, they would all be using the same key, and uh that would of course damage privacy. And if you use statefulness, like with Jonas's Shrinks idea, uh it might complicate things. Uh but there are some post-quantum cryptosystems that allow for this kind of structure. Um Project 11 recently did some great work on showing how you can do this with uh certain lattice-based cryptosystems. Um but it comes with tradeoffs. It increases the size of the signatures and pubkeys quite a bit. But what interests me personally a lot more in that realm is isogenies, because in the world of isogenies, you kind of inherit BIP32 without any modifications to the schemes, uh without increasing the signature size or changing the pubkey format or anything. So, isogenies sounds promising. What what what are the downsides? Uh downsides are it's still a very novel idea. I haven't heard it applied to Bitcoin specifically. Uh so, there is no more validation that will need to occur to know whether it's secure or not. Um I don't see any reason as to why it won't, and there are very clear ways that you can prove it secure, but I know I'm not an expert cryptographer. I don't feel comfortable stating that it's an easy proof. Um And that's why I think it's it merits more research and more funding uh because it is an extremely promising avenue for us specifically as Bitcoiners, offering that structure with very compact keys, compact signatures, and with the promise of potentially more uh fancy cryptography that we can do later. Yeah, I think it kind of kind of got a bad rep 2 years ago cuz there was that Was it SIKE or something? Yeah. Yeah. That that's probably I can talk about that for a second if you want. So, back in 2022, uh there was a uh public key exchange cryptosystem called SIDH, uh supersingular isogeny Diffie-Hellman, which was broken in a classical attack. So, you don't need a quantum computer to break this system. Uh and it was only discovered because there was an old theorem that was proven back in the '90s by a mathematician named Ernst Kani. Uh it's now called Kani's lemma. And this rediscovery completely revolutionized the isogeny crypto space. Uh it broke SIDH and uh it required cryptographers to adapt, but it also sped up uh a lot of other crypto systems. For example, one of the leading isogeny-based signature schemes, Skey Sign, it used to take a second or more to create a signature, and now it only takes a few milliseconds. And that's because of Kani's lemma. So, on one hand, yes, that attack absolutely did break some very key isogeny schemes, but it also massively improved others. Jonas, I want to maybe double double click back into hash-based. And you talked about the signature budget, but maybe we can talk about stateful and stateless. Um because I know you've been doing a lot of research there, and you can maybe work that in. >> Yeah. Yeah, so we talked about the the signature budget and how a smaller signature budget reduces the size of the signature. So, you could imagine, okay, let's choose a small number that is still sufficient probably for for Bitcoiners as long as you don't reuse addresses cuz you're not bumping the fees very often, I suppose. Maybe set it to to 10 or whatever. So, relatively small number. And then you also add the option that we call a fallback path, where if you exceed these 10 signatures, you produce a large signature with with a very large signature budget. So, you always have the opportunity to make the signature to make a signature. And you also have the opportunity to make a lot of signatures, but the first few signatures that you make, which hopefully will be sufficient, um they are really small. Like 300 to to 600 bytes depending on which exact parameters you pick. Now, the problem is how do you know how how often you have signed? You need to store that information somewhere because if you exceed the 10 if you exceed the signature budget, that may compromise your coins. So, that completely breaks the security. So, you need to remember how often you have signed with this compact path. And uh you need to remember for the entire lifetime of the wallet. So, that needs to be for example, if you're using a desktop or a mobile wallet, like the most obvious thing this needs to be um persistent across reboots. So, if you it needs to be written on disk such that uh when you reboot this that information is still available, you don't exceed the signature budget. But um what is uh a problem is uh backups, for example. So, if you whatever use your mobile wallet, you sign a couple of times, you perhaps make a backup to iCloud or whatever. Um your device breaks. Well, before you the device breaks, you produce another signature. So, maybe let's say you have made five signatures, that's backed up. But you now make another signature, your sixth one. And then the device breaks, you buy a new device, you restore the backup, the state is then five again, all right? And now uh you might think, okay, I have five more signatures, but that is wrong, you only have four more signatures. And um this is why statefulness is this kind of very fragile assumption in many kind of setups, and which is why when we initially looked at this, we thought this is a neat trick, it allows you to produce these really small signatures, but we didn't really think it was practical. There are some setups where this is really practical. For example, if you use a hardware wallet. Cuz if you use a hardware wallet, you can't if the hardware wallet is designed in the right way, you can't really mess with a state, right? There's usually not really a way to back to to back it up. So, the hardware wallet would just remember for you how often you have signed. Uh it can still happen that the state is lost, right? The device might break, but then you can initialize a new device and use this fallback path, right? Where you can sign sign as often as you want. I can sort of mention like this is a very similar problem to in Lightning Network, where you you have this channel state and you need to remember what it is. And like people have lost money through that kind of thing where you make backups and you restore the backup after using it and like get out of sync and stuff. I think the case for hash like stateful signatures is maybe a little bit easier than Lightning because you can you can look at the blockchain in many cases. Where if you're like, oh, how many times did I sign? I haven't used this in a few months. Let me restore it. I can look on chain potentially and be like, oh, apparently I signed six times, not five. So, like you do have the blockchain to look at. So, and there's there's things that help there, whereas in Lightning it's all completely off chain. And if you lose your data, like there's nowhere other than your backup. So, it's like but at the same time like, yeah, that that is a problem people have dealt with in Lightning a lot, and it's having statelessness is really nice. Um but maybe this is somewhere in between where it's like not quite as bad as Lightning. A quick analogy here to understand why statelessness is a problem and why it exists as a as a as a technical issue, you can think of a stateful hash-based public key as basically a collection of single-use tissue papers. If you use a single one, that's great, you can you can toss it away and then use the next one and so on until you're not sick anymore. But if you reuse the same one, you explode. Your your key is instantly compromised. Yeah, I think the um one of the arguments you could make for stateful signatures is that if we would use one of those standardized schemes, we have systemic risks. Like the super low throughput, no one can really use Bitcoin anymore or fewer people can. Or we use isogenies that we have the systemic risk that the cryptographic assumption ends up being broken. Whereas if we use stateful signatures, we don't have these problems. We have instead localized risks. So, instead of systemic, we have localized risk, where individual wallets can have some issues, maybe users can make um mistakes. Whereas well, I hope this can't happen because I hope those systems would be designed such that the user cannot make a mistake. But it's really it moves this the systemic risk to a more uh localized risk, and I think this is the main reason why this is attractive. One one other part I could sort of argue and get into more controversy is um the size is something people have been like that's sort of the main thing we're talking about, right? It's like, oh, well, the standard ones are too big, they're a kilobyte or they're this or or but I think time to verify is maybe like in my opinion more important more important. So, if you're like, oh, we've got this signature scheme and it's, you know, 100 bytes, but it takes a second to verify. It's like, oh, that's that's kind of useless, right? Even though, yeah, if you just think about block size, this is great. Um it's really I sort of think of block size as a proxy for verification time. Um where cuz if and and I think like if you had a signature scheme where it was like, oh, the signatures are a kilobyte, but you can verify them just as fast or faster than an elliptic curve signature. To me, that's like, oh, that's great. Then we just need to do a soft fork to increase the witness discount just and and like really, yeah, then it's bigger, but it's just as fast or faster it than it is today. And so, but but that's that's my perspective, right? For some people, they might be like, no, like I'm really space constrained. I'm internet bandwidth constrained or I can't run a full archive node if it's, you know, 5 terabytes, uh but I can if it's 1 terabyte. But to me, it's sort of like in my situation at least, like not that limited by network bandwidth, I'm not that limited by hard drive. It's mainly like when a block comes in, I want to verify quickly. And when signatures come in, I want to verify quickly. And that seems like the real reason we have these restraints on block space and stuff. Do you Hash-based signatures are um a great answer in that situation because uh we can make them both compact, but also very very quick to verify. Like to to verify a stateful hash-based signature, uh it requires less work than verifying a um uh Schnorr signature if I am I'm doing my mental math correctly. Uh a stateless signature is a little more expensive, but as some of my work has shown, you can accelerate that massively uh to the point where if you use parallelism properly, you can get it to be the same speed as Schnorr, roughly. Yeah, just just to add to that really even if we agree that uh stateful hash-based signatures are a good idea, there's still this space of potential parameters to pick. Um how much should we prioritize verification time over signature size? And the challenge will be to create a proposal with parameters that uh the fewest people strongly disagree with. We talked earlier about a waiting just 1 year cut down on the size component by 90% poten- potentially depending on the parameter usage. What do we get by waiting another year? What do we get by waiting more years? It is this is there is there a scheme to put in now uh that that is workable enough even though we use some we lose some of the feature richness? Um How how do we think about that? So, the hope with hash-based signatures is that we never have to use them. And if we never have to use them, they never affect the size of the chain at all. Now, that's a pretty optimistic hope. But, um, it's better to implement it sooner than later in my opinion. Um, mostly for the fact that the sooner we implement it, the sooner people can start migrating and the fewer coins will be exposed over the long term. Um, and the more coins that are migrated, the less we have to debate the whole freeze debate. Um, the whole the whole Satoshi's coins thing is going to be probably left in the air uh for other for other talks to debate. Uh, but there are coins that are held by living people uh who want to migrate today. I mean, I count myself as one of them. And uh having something in place for people to migrate to, um, which will also, by the way, work um, after Q-Day and uh will bolster any new signature algorithms that we add. I think that's a good idea. Um, and it what it's debatable whether hash-based signatures will improve that much in a year. I mean, Jonas, what do you think? I think this is uh really really difficult to predict, but my personal feeling is that while we at Blockstream Research we have spent some time looking into this field of stateful hash-based signatures, I don't feel like this space has been uh fully explored yet. So, that will be one of the optimizations that might might happen, but it's hard to predict really how how useful something like that ends up being. It might also add complexity and then you have this other trade-off, complexity complexity versus maybe a little bit more um efficient signatures. And then there's this this other question, which is I think a little bit unrelated to the to the signature scheme that we deploy because there are potentially ways to also do um threshold signatures. So, some of the nice things with hash-based signatures, the question is will that ever be practical? Conduition mentioned uh MPC, so that is a very heavy uh machinery, but maybe something for the future to to look into. So, I think there's still quite a bit of of research to be made, but generally I I agree that um adding hash-based signatures hash-based signatures always have this really nice advantage of the security assumptions. So, even if in the future we were to add something in the in addition, some users might still prefer to use hash-based signatures because it's just like it's relatively easy to explain um and they have these nice nice assumptions. You can implement SLHDSA in a weekend uh in Python. It's it read the FIPS spec. It's actually really approachable. May maybe you can, Conduition. >> [laughter] >> I would Okay, I'll I'll uh disagree somewhat with the the general idea. I think I think we actually have a bit more time than than in a lot like I'm sort of comparing to like the rest of the world again. I think in the case of Bitcoin, you could you could argue there's more and I would argue there's more time. Whereas with a lot of the, you know, web stuff and email and all these things, encryption, it's you kind of want to start migrating earlier because there's attacks that can sort of reach back in time, right? It's like, "Oh, intercept the data now. I can't decrypt it, but once I get a quantum computer in 5 10 years, then I can decrypt it and read your your messages or things like that." And so, you kind of want to get ahead of that. Whereas in Bitcoin, that doesn't really apply. And also, I would argue that like if you if you're like the only person that's using this new hash-based system and then like you see DLP is broken, like kind of doesn't matter, right? Like if everyone else's coins get stolen and you're like, "Hey, I'm one of the like five people whose coins are secure." It's like, "Well, okay, that's nice, but like the whole system's probably dead." Um, so I think it it is kind of a thing where you kind of want everyone to start moving. So, I don't I don't know if there's that much utility in having some new like optional thing that a few people can migrate to. So, I mean, I think it's like I would side more towards let's work on this more and not like try to get something in that soon. We have just a couple minutes left. You guys have a lot of things that you've you've wanted to say. And so, maybe if there's something that we didn't emphasize or that you think would be a good takeaway for the audience, this would be the opportunity to to call their attention to something. Go ahead, Conduition. Well, there's there's two different uh parties that you can partition the Bitcoin network into, two different groups. Um, one is the set who will who will migrate in time before a quantum computer can attack their coins. Um, I would say that set would definitely include major custody holders like Coinbase. Um, it would probably include most of the people in this room, judging by the fact that you're all at a post-quantum cryptography panel. It will probably include um most wallet developers within reason. Um, any actively developed wallets will probably be paying attention. And any users of those wallets will inherit the fruits of those developers uh awareness. Um, the people that we should be worried about are the people who tend not to move their coins at all for very very long periods of time. Um, and uh to those people, if if you're listening, pay attention to the news um, and upgrade your wallet when it's time. And we don't know uh when Q-Day will appear, but we can control when we upgrade. And once we've upgraded Oh, sorry. Once we've upgraded, um, people can start migrating. And I think earlier is better in that situation, especially for the people who don't move their coins much or check in to the news very much. I would say don't worry like we this is not this this discussion topic, but like the commit reveal and ZK like there are migration paths that make it safe even if you haven't upgraded. Like so, if you have like I've got my coins and they're, you know, buried in my backyard and I haven't touched them in 5 10 years. Um, if you haven't reused addresses, you know, haven't like hold coins on address where on an address where you've signed from that address before. Um, they're are pretty easy like not easy, but there are ways to migrate even after the fact. So, a quantum computer appears or elliptic curve is broken and you still don't touch your coins for 5 years and you show up you know, 5 years after the fact, uh there are secure ways to migrate. And so, I would say like but the main thing is don't reuse addresses. And that's like good advice even if none of this is relevant. It's use addresses one, you know, use different addresses for each time you receive, don't reuse addresses, and then you're probably fine. Um, but for those who are using it a lot, then you need to look at migrating and stuff. Jonas. Yeah, I think for for me right now there are three main question. One is are there any additional optimizations that we can um apply to these stateful signatures by using the statefulness assumption because maybe we haven't explored the space entirely. Um, second, what are the safe setups to use stateful signatures? I mentioned hardware wallets, but there are potentially also others. And third, how do these signatures interact with uh layer twos, with lightning network payment channels, um etc. And um also I would like to mention that uh we have an implementation of of stateful signature schemes in in liquid that uh you could use today, a C++ implementation, as well as an implementation in simplicity. So, if you want to explore those with uh real LBTC, then you can do that today. Our time's up. Thank you guys. Thank you guys for attending. >> [applause] [music] >> Every year, this community comes together to celebrate, [music] to debate, to build what comes next. >> [music] >> And every year, the stage gets bigger. Sound money, center stage. [music] So, where do you go to celebrate the next chapter in Bitcoin history? You come home. >> [music] >> Nashville, July 2027.