A concise breakdown of why Bitcoin’s current signatures are vulnerable in theory, what quantum risk really means, and why careful preparation matters more than rushing changes.
In this episode, cryptographers Jonas and Mikhail unpack why Bitcoin’s current signature scheme (secp256k1) is theoretically broken in a post-quantum world and why that matters even if quantum computers are not imminent. They explain how quantum computers could derive private keys from exposed public keys, why obfuscation techniques like MuSig or FROST wouldn’t help, and why post-quantum cryptography inevitably comes with trade-offs. The discussion centers on hash-based signature schemes, particularly SPHINCS+, as a conservative, emergency-ready option because they rely only on hash functions like SHA-256, which Bitcoin already depends on. However, these schemes introduce significant downsides: much larger signature sizes, slower signing, limits on how many times a key can safely sign, and incompatibility with many features Bitcoin users take for granted, such as HD wallets, xpubs, and multisig workflows. The guests walk through optimizations that can shrink signatures by lowering unused assumptions (like supporting 2⁶⁴ signatures per key), explain why stateless designs are safer than stateful ones for Bitcoin users, and outline realistic migration paths, such as adding post-quantum script paths inside Taproot, so Bitcoin can prepare without rushing into irreversible changes.
“The assumption that secp256k1 is not broken is actually wrong.”
“Whenever the adversary sees a public key, they can compute the private key.”
“Hash-based signatures are as conservative as you can get in terms of assumptions.”
“If SHA-256 is broken, we have much bigger problems than signatures.”
“Post-quantum security is never free, there are always downsides.”
“Moving too fast can be just as dangerous as doing nothing.”
The conversation makes clear that Bitcoin does not face an immediate existential crisis from quantum computing, but it does face a real long-term risk that cannot be ignored. Hash-based signatures offer a credible, conservative fallback that could be deployed in an emergency, yet they would fundamentally reshape wallet design, usability, and on-chain efficiency. The guests argue that the right path forward is neither complacency nor panic, but careful research, benchmarking, and open discussion, so that if the threat materializes faster than expected, Bitcoiners are not scrambling to make irreversible decisions under pressure. Preparing thoughtfully today is what preserves Bitcoin’s security, neutrality, and credibility tomorrow.
0:00 - Intro
0:32 - Explaining hash based sigs
5:20 - Post-quantum
9:49 - SPHINCS+
16:43 - Signature size
19:51 - Bitkey & Obscura
22:12 - Potential optimizations
28:11 - Stateless sigs
31:20 - HD wallets
36:56 - SLNT & SOTE
39:38 - Other sig schemes
44:11 - How close is quantum?
51:02 - How to transition
1:02:20 - Dangers of haste
(00:00) It will make it easier for an attacker to actually forge a signature which in Bitcoin would mean that they could be able to steal your coins. Whenever the adversary sees a public key, they can run their quantum computer and compute private key that's corresponding [music] to it.
(00:16) Music or Frost or any obfiscation attempts will fail. This assumption that SEP256K1 is not broken is actually wrong. The challenge is just to build a machine that exploits quantum mechanics enough to break it. Jonas and Muel, welcome to the show. Thank you for joining me. >> Thank you for joining us. >> Been a been a big week. You guys you guys wrote a paper.
(00:43) There's a lot of uh discussion on it on X and other platforms. The paper is uh hashbased signature schemes for Bitcoin. And you guys are >> in this paper trying to tackle the the question of okay if quantum computers do manifest and people need to protect their Bitcoin what is the optimal um sort of solution to that problem to make sure that bitcoiner bitcoiners are storing their bitcoin and addresses that can't be attacked by quantum computers among other things.
(01:16) Um, but first I think we should start thinking of someone who doesn't have a cryptography background. Can you just explain what hashbased signatures are, why they might be important for Bitcoin's futures, and why hashbased um, signatures in the first place? >> Mhm. I I think I can start and then Mike can fill in the the details that I'm I'm missing.
(01:43) So, um, the where do we use signatures in Bitcoin? We use it to authorize transactions and um the current signatures that we use they are uh based on on the security of an elliptic curve that's called SEC P256K1 in Bitcoin. It was chosen by Satoshi. Um there are alternative signature schemes that depend on different assumptions and um one of those alternatives are hashbased signature schemes and all of these alternatives they have different tradeoffs.
(02:21) We started looking at hashbased signature schemes um because the assumptions that they use they are relatively conservative compared to uh other signature schemes and um hashbased signature schemes that just means that the signature scheme is the security of the signature scheme is based on the security of the hash function.
(02:50) And why is that attractive for Bitcoin specifically? Well, we already are relying on the security of SHA 256 for example. This is how we refer to previous blocks in the blockchain. This is how transactions get committed to a block in uh the Merkel tree. And from that perspective, we started looking at these hashbased um signatures first.
(03:15) Essentially it's also important to say for most of the other approaches that one can consider whether it is uh there is one popular called letis based schemes that require some other assumptions most of them still rely on hash functions. So this is essentially as minimal as you can get in terms of like security assumptions and requirements from a scheme is uh requiring just a hash function to be secure.
(03:51) This is uh a very conservative approach and I guess arguably the most secure uh way the possibilities this has the least amount of attack vectors in that regard. >> So Jenn you referenced it. So Bitcoin already relies on shot 256 for mining and transaction IDs. So this is just sort of a doubling down on what's already worked to date and what we know to be pretty secure.
(04:20) >> Right. Right. So we can so hashbased means we can use any hash. Um there are also different hash functions we could choose also with different tradeoffs with respect to performance or even proving uh uh proving in zero knowledge snarks. Um but uh the natural choice for the hash function would just be SH 256 because if SH 256 is broken then argu arguably we have even bigger problems than just transaction authorization not working.
(04:52) The blockchain doesn't really work anymore. [laughter] Um we don't know what the truth is. We we don't have consensus on the blockchain anymore. So um yeah from that perspective um makes sense to look at these hashbased signature schemes but they have a reputation uh for being quite large in terms of size. So that is that is a consideration that um that one needs to look into when uh uh when considering hashb signatures. Mhm.
(05:21) And before we get to that, cuz I think that's exactly what your paper focused on, like, okay, if we want to be quantum resistant, we're going to use hashbased. How do we basically weigh the trade-offs and make sure that Bitcoin is still usable and scalable at the end of the day? But before we get to that, even like we've all heard the term postquantum thrown around.
(05:41) What does that actually mean? Like what is the quantum we're supposed to be afraid of and supposed to be preparing for? >> Yeah. So I think so from my perspective if we if we as cryptographers do security proofs so for example for schnore signatures or music or frost or signature aggregation dalas etc. We have these little theorems.
(06:08) They are a paragraph or two contain some numbers and they very precisely state what the assumptions are under which these signatures are secure and um in the case of schlor signatures it tells you directly when you read it or write it down uh it relies on the security of this curve that you're choosing sepk1 in the case of bitcoin and Um we know that this uh this assumption that SEC P256 K1 is not broken is actually wrong.
(06:46) Uh it is broken. You just the challenge is just to build a machine that exploits quantum mechanics enough to break it. But um this is different from other types of cryptography. We can also do cryptography where we don't have assumptions like that. So just writing this down this statement personally makes uh makes me a little bit uneasy as well.
(07:12) Um so um a quantum computer would be able to break uh our curve and [snorts] therefore would be able to break shore signatures. Now the challenge of postquantum cryptography is to find um cryptographic schemes that are secure even in the presence of quantum computers and that um requires also some sort of guesswork or some research as to what problems quantum computers are actually good at.
(07:44) We know that they are very good at uh breaking our elliptic curve and they are it's very unlikely that they are good at breaking uh hash hashes let's say they are better than classical computer but they won't be able to break it in a way that they can break um elliptic curves and essentially what I can add here is that we even sure [snorts] that the quantum computers cannot do certain tasks uh good enough to breaks uh the security of that.
(08:17) For example, uh if we have a database a random database and uh we ask quantum computers to search for a specific input in that database but we don't know where it is. We know that it is a hard problem for quantum computer and you cannot do better than certain complexity. Yeah. And the hash function is essentially is this random database because we take an input, we hash it, we get a arguably randoml looking output and uh our assumption here is that uh we will not find an algorithm that can exploit the actual description of the hash function.
(08:59) But uh one can view this very similar to how classical analysis of hash functions works because uh classically we also rely on that we cannot find an algorithm that can exploit the actual description of the hash function. the actual algorithm that does the hashing and so far shadow 156 was not under good attacks there.
(09:30) It it proved its security and there was no significant improvement in terms of exploiting the structure. So for any quantum advances there there must be a structure in the hash function that can exploit and uh so far we couldn't find anything like that. >> Okay. And so let's dive back into the paper and run with the assumption that quantum computers could exploit that hash function at some point in the future and talk about the trade-offs.
(10:01) in the paper it seems like you guys settled on Sphinx Plus um as a standardized solution because it already exists. It's already standardized by the NIST. Why do we need this research? What's the gap that you guys are trying to fill um by applying this to Bitcoin specifically? >> Yeah.
(10:24) So uh NIST has looked at um which postquantum signature schemes to standardize and they picked uh so they picked uh multiple one of them was sphinx plus that they standardized but um so sphinx plus exists we could use it there exists in in bitcoin I mean there exist high quality implementations with formal verification and proof etc. So we could just use it.
(10:51) Um but um the kind of research question that we had when we started the the paper was the um [snorts] kind of goal of signatures usually outside of of Bitcoin or or blockchains is to sign software and to sign um certificates for for the web. And this is a very different application to what we're doing in Bitcoin with signatures.
(11:18) Um so what what we were asking was can we adapt this standardized scheme or also other schemes that exist in the literature that have not been uh standardized and see how um in what way we could change them to better fit to this uh Bitcoin application. And again, one of the trade-offs that we're trying to solve for here is the size of the signatures.
(11:51) In the paper, you mentioned going from about 7,800 bytes down to around 3,400 to 4,000 bytes with optimizations. I think for the listeners out there, getting them to understand like why does the size of these signatures matter? What's the trade-off that you're making? >> Yeah, I think Mike can speak best to that. >> Yeah.
(12:13) So first of all the size uh determines how many signatures can you fit in the block and then the bigger the signatures the fewer transactions you can you can fit and that uh determines >> so so in a in a current block that is right we have these maximum four megabyte blocks and then if your uh signatures are suddenly huge then you can of course fit fewer transactions in the block unless uh you increase the block size as well.
(12:40) which is another topic. Yeah, >> has its own ups and downs. Uh but yeah, if if we consider that for now that the block stays the same, uh the the size matters on on the bend. Uh this is one thing. Another thing is that um the swings plus was designed to support a lot of signing operations. So the requirement for the NIST was for the people to be able to sign two to the 64 um different messages.
(13:16) >> So that's yeah just to add to that that's a a number with 19 digits. So it's a huge number. It's practically infinite. >> That that was exactly the idea is like okay we set up this bar that [snorts] will be never reached. You don't have to worry about it. is 2 to the 64 is huge for all practical applications.
(13:38) You just don't need to think about it. There's no problem. And uh this uh requirement for hashbased signatures actually determines a lot in terms of the size. And uh the first observation that we can make is that if we set this bar lower and we actually can uh have a limit on uh less number of signing operations we can significantly decrease uh the signature size.
(14:10) >> Moreover, with the signature size uh the verification time can also be decreased and the verification uh determines on how the how fast can we validate the block, how fast we then can propagate it and and so on so on. So this this one of the core observations here. Uh if we speak of another improvements is that SH plus uh there was a process of standardization and the ideas were coming and certain improvements were made but they had their own timeline and so they had to decide uh at a certain point uh what we
(14:51) accept and what we standard types but the research didn't stop there and there were different modifications and different improvements also suggested And uh we can use those as well in uh in the Bitcoin uh >> so >> environment. Yeah. >> When this sets these standards, do they ever change? Can you have updates to the specific standards on Sphinx Plus or if you're going to go use the other ideas that were um that were suggested but not included in the standard is obvious if you include those are you out of N standard and is that is that frowned
(15:32) upon or just considered experimental? >> So if we deviate from the standard now then yeah we're we're using a different one. uh theoretically uh modifications uh can be done to the standard and there can be an update, there can be a different standard or just just a new version of that. Uh there are different also like modifications that we can do.
(16:02) One can just use different parameters and for example this way it will be easy to reuse uh some other implementation but uh the some modifications that we discuss in the paper also affect some of the structure of the signature scheme that we'll have to adjust the implementation as well. So this there are various options that we can use that give us certain uh performance boosts or sizes boost or um other tradeoffs and they come also in the cost of like varying further from the standard or sticking more with it.
(16:44) >> And so we already talked about one trade-off which is the size of the signatures. I think the other one, one of the other ones that you discussed um in the paper is if you if you have um like heavier signature sizes and bytes in terms of bytes um you could sort of limit the amount of signatures that uh any public key it can be associated with any public key.
(17:12) What's what's the >> I think this is a strange technical thing that one needs to get his head head around, right? If right now in our world of signatures, we don't care how many signatures we do. It's just a technicality of these hashbased signatures that when you design such a scheme, there is a limit of signatures you can make per public key.
(17:38) And to be clear, it's not our I we were not the first to come up with reducing the number of supported signatures. This is a pretty obvious idea when you when you look at uh those schemes, how they are structured. Um but one of the insights that you might have when trying to apply this to Bitcoin is just that in Bitcoin, specifically in Bitcoin, we don't need that many signatures, right? We create an address.
(18:09) Usually, we only want to use it once. We don't want address reuse. And then we sign, produce a transaction. That's it. Then you might have to do RBF to bump fees, then you have to sign again. How often does that happen? Maybe it happens more often in if there's more a more competitive block space market.
(18:30) Doesn't happen often right now. And it certainly doesn't happen to to the 64 times. Um there are other things where you need to sign more often for example in in layer 2. So uh lightning so that payment channels that's that's sort of a different discussion perhaps but you still won't sign that many times. still going to be an upper bound that is below to the 64.
(18:53) And um yeah, using those ideas, we can get down uh this the signature size. Um and yeah, as I said, this is quite quite a technical quite a technical thing very peculiar to these to these hashbased uh signatures. Lower number of supported signatures means uh you can get a smaller signature.
(19:17) And um what happens if you sign more often? I think that's important to explain. So if you have a a signature scheme, hashb signature scheme that supports let's say uh a thousand signatures and you do more then the security sort of degrades. So, it will make it easier and easier for an attacker to actually forge a signature, which in Bitcoin would mean that they could be able to steal your coins, make a malicious transaction to steal your coins.
(19:46) So, you should really, if you have that limit of supported signatures, you should not exceed it. You must not exceed it. So, for this was brought to you by our good friends at BitKey. Bit Key is the hardware wallet that makes Bitcoin easy to use, hard to lose. It's a two or three multisig. You download the mobile app, you pair it with this hardware device here.
(20:07) Uh you have a key here, one on your mobile app, block holds one in the cloud. Comes with incredible features. The newest of which is chain code delegation where you can set up your wallet and you can send and receive Bitcoin from that wallet as long as you're doing it with your hardware wallet and your mobile wallet.
(20:26) And block is none the wiser. You get privacy with chain code delegation. in privacy mode. You can auto stack using Cash App, Strike, Coinbase, other apps uh directly to your BitKey wallet. Uh easy to set up. If you have friends and family that still have their Bitcoin on the exchange but need to get it off, send them to BitKey uh to pick up a bit.
(20:45) Go to bit.world. Use the code TFTC20 for 20% off your BitKey and you can buy one right here. We have one in our YouTube store. You don't have to go anywhere. Just click that link. Use the code TFC 20% off. pick up a bit key. >> Sup freaks, have you noticed that governments have become more despotic? They want to surveil more.
(21:06) They want to take more of your data. They want to follow you around the internet as much as possible so they can control your speed, control what you do. It's imperative in times like this to make sure that you're running a VPN as you're surfing the web, as we used to say back in the '90s. And it's more imperative that you use the right VPN, a VPN that cannot log because of the way that it's designed.
(21:25) And that's why we have partnered with Obscura. That is our official VPN here at TFTC built by a Bitcoiner Carl Dong for Bitcoiners focused on privacy. You can pay in Bitcoin over the Lightning. So, not only are you private while you're perusing the web with Obscura, but when you actually set up an account, you can acquire that account privately by paying in Bitcoin over the Lightning Network.
(21:46) Do not be complacent when it comes to protecting your privacy on the internet. Go to obscura.net. Set up an obscura account. Use the code TFTC for 25% off. When I say account, you just get a token. It's a string of token. It's not connected to your identity at all. Token sign up. Pay with Bitcoin. Completely private.
(22:07) Turn on Obscura. Surf the web privately. Obscur.net. Use the code TFTC for 25% off. Yeah, it's it's funny. We're getting Again, I talk I say this a lot, especially when I talk to developers and cryptographers like yourself. is like so many people take for granted that the system just works and not understanding these these deep deep cryptographic primitives that exist but it is always infinitely fascinating um diving into these details because I think it's important even if you're not technical to sort of have a a rough
(22:39) understanding of what's happening under the hood um and obviously we talked about sphinx plus some of the optimizations there but we also talked about watts plus c force plus c pores plus fp as potential optimizations. U I guess without getting too far into the weeds, what what are the ideas with uh these optimizations? >> I think I can I can give some some overage here.
(23:08) So the core idea is here is um we can uh make the signer to work a little bit more on finding uh certain inputs. So except uh we don't only include the message but some extra seed or [snorts] an an extra uh random number or a counter uh and that allows us to search for better values that we can then sign and uh this requires some extra work from the signer.
(23:44) But because we have this extra properties from what we are signing uh this can reduce the signature size and this also helps the verifier. So by doing extra work on the on the signer part uh we reduce the size and we reduce the verification time. Sometimes this extra work also uh comes in the cost kind of yes we we search for this for this uh nice value to to sign afterwards but because this value is nice this also isn't the further work for the sign.
(24:23) So uh we had these different parameters choices uh in the paper and for most of them we make the signing time a little bit more than uh the original sphinx plus because we want more effort from the signer but really smaller signatures but on the other hand we can still balance this out while keeping the signature size small and >> so this would affect wallet software right because I'm thinking of I played around with some DLC apps, Atomic Finance, and when you go and you're doing like a rollover transaction with
(24:59) DLC's that take a lot of signatures, it sometimes takes like a minute or two to actually sign and then broadcast the transaction. So, this wouldn't necessarily affect uh the nodes, right, and bandwidth propagation and things like that. It's just literally on the setup to sign and then broadcast. Correct. >> Yes, I think so.
(25:21) I think this is is a very interesting point that that you're making right now that I hadn't really considered before. So, um I think this kind of tradeoff between in increasing the signing time while reducing signature size and verification time makes a lot of sense in Bitcoin because at least on the Bitcoin blockchain, we have a natural limit of the number of transactions that are supported per second, right? We can at most like whatever 10 transactions per second and few more signatures than that whatever but it's not thousands of
(25:56) signatures per second that you need to make. On the other hand we also have um hardware wallets uh that are of course lower powered and that might take longer and um I think what you're pointing out is an interesting thing. You might have situation where uh you are pre-signing a lot of uh transactions and this is what is happening naturally in in DLC's uh right now and um this this would be affected by a change like this um by a change to to hashbased signatures because producing these signatures depending on which parameters you you
(26:34) pick which is I think the biggest part of our work trying to figure out what are reasonable uh parameters it might take much longer to sign them than they it takes currently. >> Yeah. And that's the trade-off you have to weigh. Are you willing to wait more to broadcast a transaction, >> right? More generally perhaps important to say that in this postquantum world, we always have to uh deal with downsides.
(27:04) There's no This is also something that I feel like people on on Twitter sometimes misunderstand because they are asking why haven't you done anything uh right now already perhaps we would have we would [snorts] have changed to uh um more conservative assumptions in terms of signatures if it was for free but that's not the case whenever we want to uh add postquantum security to Bitcoin we get very significant ificant downsides be it new assumptions uh signature sizes verification time signing time statefulness um so there's no we can't
(27:44) just we there's a big risk I think to um just try to switch something which we later figure out wasn't the right choice because it picks the wrong trade-offs so what we are doing mainly in this paper is to explore the trade-off space particular with respect to hash based signatures to inform uh the community as to what are reasonable parameters uh to pick.
(28:11) >> Yeah, that makes a lot of sense. I mean, you mentioned statefulness and you guys touch on it on the paper, stateful versus stateless um signature schemes. Why is being stateless so important to Bitcoin specifically? >> So, yeah, stateful versus statelessness is a is a good topic as well here. What does what does a stateless versus stateful mean is that uh again now we don't have to think about its is essentially stateless and uh what does mean is that when you sign you don't have to touch your secret key uh in terms of change it and update it
(28:52) uh it stays the same and you can kind of in more or less implementations you can separate it you can back up it as it is there is no problem everything again stays the same. When we say stateful stateful hashbased scheme means every signing operation must update the secret key.
(29:14) And uh if there is a misuse of this secret key or the update didn't go through or you lost some key and you run a backup [clears throat] that has an older state of the key that will uh compromise the security of the skin. But it comes from the other side with benefits of having again better performance and better sizes with a stateful scheme.
(29:39) If you if you if you're happy with this secret key manipulations, you can have better performance. But uh it's important to mention yes, this this can be very tricky. For example, if you have just two separate devices and you want to run them with the same uh key pair, if they don't communicate with each other, maybe you can separate the states, but that will limit the the number of signatures that they can provide, but there is much involved there in that regard with managing your your keeper.
(30:14) >> Yeah. So the state management thing I think is another very technical thing but that is kind of important when trying to pick these uh schemes. Uh I think state fullness is pretty fragile and it's one of those things that won't work for every signer. So another example is so you run Bitcoin core on your node.
(30:39) Um let's say you produce a backup you back up your wallet. uh you make a few transactions perhaps and uh your uh machine crashes whatever it break your machine breaks you need to restore the backup that you've created including the wallet.ndet and if you do that and the state would be stored in the wallet.ndet that which of course no one would do but if you did that then uh essentially you would uh allow an an attacker to produce forgery steal steal your bitcoin so that is why it's very fragile and it won't work for everyone so for example it won't
(31:14) probably won't easily work for clear okay I guess another thing that this affects too though is like HD wallets hierarchal deterministic wallets you mentioned the backup system that we rely on again they don't work the same way with hashbased signatures either. So what uh what do we do with HD? Yeah, I think this is one of the the other uh sort of downsides of hashbased uh signatures is that they don't have this nice mathematical structure that we currently enjoy on our elliptic curve.
(31:52) uh which means that we cannot use any of the tricks that we've developed uh over the past uh year years in in Bitcoin and that includes HD wallets in it includes uh multi- signatures, threshold signatures, silent payments, aggregate signatures and tap routt I guess tap routt commitments.
(32:19) Um so um that was one of the other uh uh research questions that we also had when we started this uh entire project is um is there anything we can do with hashbased signatures? Uh in the past it was sort of um um it was intuitive that it wouldn't work but I thought maybe we could do something here or there and improve uh improve on at least the trivia things.
(32:44) Um uh I think the answer is mostly we can't really do anything fancy there. We describe some methods in in the paper that um would reduce the size of multi- signatures by a little bit but it makes the signing protocol very complicated and there are other techniques like that that you could use especially for multi and threshold signatures.
(33:11) Um it's not maybe there are some scenarios where you could use them. Um but right now it doesn't seem uh it doesn't seem to make a lot of sense to uh base the entire um standardization effort and picking specific schemes just to make it a work a little bit bit better with these multi- signature schemes because they don't really work that well.
(33:36) >> Yeah, they don't give much there. And for HD wallets um there we have so HD right is is multiple things. One is uh private um derivation and public derivation. So what you can have still with hashbased signatures that works very straightforwardly. You have um a seed and you can generate many addresses from it perfectly fine. Um works well.
(34:06) uh what you can't have is this kind of x pub where some other person would or some other entity would derive uh new public keys from some given xpub. Uh that does not work and this like this xub system xop setup is particularly important today in hardware software wallet setups. You have your hardware wallet export your x popup from the hardware wallet to the software wallet.
(34:35) software wallet is then able to to derive new uh addresses and scan scan the chain in in that way and that wouldn't be possible anymore with hashbased signatures. what you need to do instead. So the only thing we know of is you have your Xpub is not a short public key but rather a list of a long list of public keys that you give to the software wallet and once this list is exceeded the software wallet needs to talk to the hardware wallet and ask for more public keys again.
(35:14) So it's not impossible, but it doesn't work as well with the infrastructure that we've created with uh descriptors uh in the past. And um there is also this kind of um worry that because it's a little bit harder to make this work that people would or wallet developers might uh uh decide to just reuse addresses for example instead of uh building the building this system.
(35:42) That would bark a lot of things there. >> Yep. >> Yeah. So is like if you're a listener, I think one of the examples that Jonas just walk through like say you have a cold card and you want to set up the private public key pair offline using the wallet and then you want to put it in a safe or something but you want to be able to receive Bitcoin to it.
(36:04) So you download Sparrow, you export the Xpub to Sparrow and then from there you can get these addresses. This would be made harder. You'd have to do it a different way with these hashbased. Then similarly with multisig, you share xpubs with your quorum partners to make the multisig xpub and that would be made impossible hashbased signatures.
(36:27) >> Right. Right. This is another another kind of scenario that sort of wouldn't work as well anymore. >> Mhm. >> That seems like a pretty big change. maybe something uh we should talk through >> at this at this >> well it might be I mean there are other uh we said it's not only hashbased signatures there are other uh um assumptions we can base and they support they might support these kind of scenarios better but they have other downsides >> freaks have you noticed that governments have become more despotic they want to
(37:02) surveil more they want to take more of your data they want to follow you around the internet as much as possible so they can control your speeds, control what you do. It's imperative in times like this to make sure that you're running a VPN as you're surfing the web, as we used to say back in the '90s.
(37:16) And it's more imperative that you use the right VPN, a VPN that cannot log because of the way that it's designed. And that's why we have partnered with Obscura. That is our official VPN here at TFTC, built by a Bitcoiner, Carl Dong, for Bitcoiners focused on privacy. You can pay in Bitcoin over the lightning. So, not only are you private while you're perusing the web with Obscura, but when you actually set up an account, you can acquire that account privately by paying in Bitcoin over the Lightning Network.
(37:43) Do not be complacent when it comes to protecting your privacy on the internet. Go to obscura.net. Set up an Obscura account. Use the code TFTC for 25% off. When I say account, you just get a token. It's a string of token. It's not connected to your identity at all. Token sign up. Pay with Bitcoin. Completely private.
(38:04) Turn on Obscura. Surf the web privately. Obscura.net. Use the code TFTC for 25% off. What's up freaks? Been seeing a lot of YouTube comments. Marty, your skin looks so good. You're looking fit these days. How are you doing it? Well, number one, I'm going to the gym more. Trying to get my swell on.
(38:24) Trying to be a good example for my young sons to fit healthy dad. But part of that is having a good regimen, particularly staying hydrated, making sure I have the right electrolytes and salts in my body. That is why I use salt of the earth. I drink probably three of these a day with one packet of salt the earth. I'm like in the pink lemonade right now.
(38:43) It's my flavor of choice. Uh this is their creatine. I've added this to my regimen. They have it in these packets as well. Uh makes it extremely convenient if you're traveling. You want to work out while you're traveling, but you don't want to be carrying a white bag of powder and going through TSA. It's very, very uh nerve-wracking at times.
(39:00) You have to explain, hey, it's it's not what you think it is. It's creatine. I'm trying to get my swell on. Um, make sure you're staying hydrated. I have become addicted to these. It's made my life a lot better. I can supplement this for coffee in the morning and be energized right away.
(39:19) I can supplement I can bring the creatine wherever I need to. Just put a couple packets in here before I head to the gym. Bring this to the gym. Drink it out of a glass bottle. Make sure I'm not injecting any microplastics into my body. Go to drinksotay.com. Use the code TFTC and you'll get 15% off anything in the store. That's drinks.com. Code TFTC.
(39:38) >> Well, that was going to be my next question. Obviously, this research paper was focused on hashbased signature schemes. Um do you guys plan on doing more research on different signature schemes moving forward? >> Yes. So our current plan is also to look at lettuce based schemes as exactly Yonas mentioned is uh although the lettuce base they introduce extra assumptions because it's called lettuce base so they based on lettucees as kind of structure and then certain with certain heart problems.
(40:13) uh but uh they can potentially offer these upsides in terms of uh hardware awards, public key derivation, multi- signatures and stuff like this. So for now I think it's a little bit early to talk uh in details about that but this is this is the followup that that we're currently working at. >> Yeah.
(40:41) And I I also think it's important to note that this entire postquantum story for for Bitcoin is a spectrum from what do we do in an emergency if it happens now let's say might not even be a quantum computer could be uh just our curve is broken classically uh that's a scenario that some people bring up and how can bitcoin really work in a postquantum future and those are are different questions.
(41:09) I think because when we want Bitcoin to work in a postconum future, we need to make sure that people can can still make transactions and they are not just uh like a few transactions that can make it into the chain because the blocks are are so uh small compared uh compared to the signature sizes.
(41:27) So those are different questions and then there's this spectrum in between where we look at okay maybe this won't be the perfect solution um but at least it doesn't rely on these crazy assumptions and I think this hashbased signature schemes is more on the sort of emergency something we could uh get consensus on relatively easily whereas the uh latispace stuff is a little bit further away on on that uh spectrum.
(41:58) Yeah, there would be a lot of reshuffleling if we had to do if and potentially when we had to do this transition. So, being prepared for it. >> Also, there's uh it's also possible to add multiple signature schemes to Bitcoin and even the hashbased uh hash even just looking at hashbased signatures, this might be a viable path forward because there are just so many different types of signers.
(42:24) there are these I don't know pleb hardware wallets and there are uh pleb uh uh lightning nodes and there are also big exchanges and uh they have different requirements and uh even just uh for hashbased signature schemes this might mean that it makes sense to add hashbased signature schemes with different parameters. This has downsides as well.
(42:53) Of course, it increases the complexity of the of the Bitcoin protocol uh which we want to keep relatively small because uh this might result in chain splits or other vulnerabilities in in bugs if we have if if if there actually is something that that goes wrong. And um so uh another downside will be that uh it reduces privacy.
(43:26) One of the um big uh uh uh advantages of introducing tap routt right was that every transaction should look like every other transaction. um even at least in the best case and uh to improve privacy and if we introduce these many different signature schemes now this might be a problem because now you can look at the blockchain and just follow certain paths of transactions and maybe certain wallets they have uh uh identifiable fingerprints and so on.
(43:55) So these are the downsides if you add uh multiple signature schemes but it's certainly possible. So you get degradation and privacy via process of elimination of >> different people using different signature schemes. So >> yes >> yeah that makes sense. Well I guess this all comes back to like how how real is this threat? How imminent is it or far away is it? How much time do we have to prepare? Obviously Jonas you mentioned like there is the potential for classical means you don't even need a quantum computer just to break the
(44:28) curve. But I think a lot of the discussion is on quantum specifically and obviously early this year you had Google's willow chip uh made a lot of headlines. I think the um the sort of advancement there was 105 cubits uh computations that would take supercomputers 10 septellion years to to perform um and is that advancement enough to to make Bitcoin Bitcoiners wary? And then another thing which is I'm trying to wrap my head around reading people's reactions to the um the quantum discussion this week is like how
(45:06) how much signal is in these advancements whether it's Willow or other quantum advancements that have been made recently. I've I've I've read people explaining that some of these advancements have sort of hard-coded um variables or assumptions in them which are sort of cheating in a way. Um and even if Willow got to 105 cubits and it was legitimate and I think it there's a very good case to be made that it was Bitcoin's cryptography would require around 13 million cubits working in parallel to to break the curve. So like
(45:44) how how viable is that? How realistic is that in a timeline of 5 10 15 years? >> So I I'm I'm not a quantum engineer and I think there is no consensus at least among the expert um when this will happen. My angle on this is that I told you we we write these theorems they rely on the elliptic curve.
(46:11) We know the elliptic curve is broken. This makes me uneasy. Uh I want Bitcoin to be secure and that includes my own little stash. I want it to be secure against very very powerful adversaries. Uh and I don't want it to only remain secure if some random guy on Twitter turns out to be right. So I think uh the Bitcoin community should certainly look at this problem and this is why we we are working on it.
(46:42) uh I right now I wouldn't lose my sleep over it for sure as well. But on the other hand um uh 10 years in Bitcoin even is not such a long time if we need to prepare for for an upgrade like like that. Uh you said it yourself the HD wallet stuff for example that would completely be broken. So we need would need to have an ecosystem update for that.
(47:06) Maybe that doesn't take 10 years, but people migrating their coins, uh, the more time they have, um, uh, the better. >> Yeah. Yeah. I mean, it's very hard to just say, okay, this will be in 5 years, 10 years or whatever years because the advancement goes from every possible direction. As you said, for example, counting the number of cubits, there is a very interesting point in terms of uh it's a little bit different from how the classical uh computers work in terms of we need several physical cubits to encode a one logical means one logical
(47:51) is that we actually performs like we expected it to perform because there is a lot of noise in the quantum computations and one need to eliminate that noise to actually do proper computations. So one can increase the number of those cubits. One can improve the this noise cancellation algorithms. Then it also very important in terms of the quantum algorithms that actually solving the problem.
(48:22) And for example there was a recent advancement that reduced I think by 20 times the number of uh cubits that require the algorithms there. So the advancement go from different directions. I would agree with Yonas in terms of I would not lose sleep today but we have to work towards the solutions to to be ready.
(48:47) If we just delay, delay, delay, then we never come there. But now we have to work and uh progress and see what what possible uh solutions we have and prepare for for the downsides uh and changes that that these solutions bring. >> How would um how would you two describe your um what's the word I'm looking for? Are you uh are you happy with the amount of focus on this? Obviously, BIP 360 um has been talked about for for the last I mean before it was BIP 360 even um people have been talking um about this hunter and his work.
(49:30) People have been looking at that and discussing it uh for what seems like over a year now. At this point, obviously you two have done a ton of research. We had the the quantum meeting at Presidio Bitcoin in July. Is there enough discussion in your opinion on this topic right now? Are are pe enough people focused on it and taking it seriously? >> And of course it would always be better if there was more quality discussions but uh I think the type of discussions that we have right now is is is pretty good and has also increased quite a bit
(50:05) especially over uh over the last year. So like you you you like on Twitter there there was not only noise. I think there was also a bunch of of signal and it was good that even the wider Bitcoin community also talked about this and talked this through and um on the Bitcoin mailing list there's always a bunch of discussions.
(50:27) Of course, there's always this kind of Bitcoin thing that might happen where just there is some discussion and then there's there's no followup. Nothing ever happens, right? This is pretty [snorts] standard thing that happens in Bitcoin. Uh but I'm also not too worried about that to be honest because I think if it really if it was really uh if if the quantum computer was imminent then I think the the Bitcoin community would fight consensus on on some sort of upgrade.
(51:02) What is of course going to be really really painful and there's no way to sugarcoat it is what happens with the coins that don't migrate. And I think this will be extremely painful, but that's not something that that cryptography can solve, unfortunately. >> What's your take there? I'm a I'm a don't do anything with them.
(51:24) Let them let the treasure hunts begin. That's I think that's my stance because you always have to think of the man in the coma, right? which is if you were to change or make their coins unspendable and the guy wakes up and he's like, "Hey, I have five Bitcoin here that I can't move anymore because you did something and quantum computers haven't stolen it yet.
(51:51) " Um, you're sort of screwing that guy over. >> I think there are reasonable uh arguments for or both for both positions. That's what makes it painful. And um I don't know I I guess my opinion right now is that if I look at it extremely selfishly what code would I run on my note then I think it would be the one that uh that freezes the coins because that at least I think in the mid to long term it would probably result uh in a better outcome for the for the Bitcoin network.
(52:25) But yeah, you could fight counter arguments to that I'm sure. Yeah, I thought um I followed the uh the discussion on the mailing list. I've been following it. I thought earlier this year I think there's still a lot of assumptions baked into this, but I thought Ethan Hailman's uh post on this was interesting how you could essentially throttle the transition and only make a certain amount of transactions from quantum exposed signatures possible per block.
(52:56) Um, is this this uh hourglass idea? >> I think so. I'm pretty sure. Uh, let me see. It goes all the way up. I think it is. He also said it was a way to solve the uh the JPEG spam as well. But this idea that that's the other thing. Maybe we should just dive into the trade-offs that exist um with what you do with the coins that that haven't haven't transitioned.
(53:28) What are the solutions that are being thrown out there right now or the trade-offs that exist? >> I mean, I I personally haven't to looked too much uh into this. I know that there is a discussion on the mailing list and there probably should be more more discussion. I I don't know. But as I said, there's no no easy answer to this.
(53:52) I wouldn't be able to reproduce all the pros and cons there. >> All right. Well, then taking it in a different direction like how like obviously you guys are doing research. There's a lot of discussion about this in terms of like a first step beyond research and having the discussions. What would a transition to a postquantum signature scheme look like? Like how do you prep the market? How do you begin moving? How do you set up the node software to make the stuff viable? Um as for the next steps that we envision after this paper. So one thing
(54:36) that is a contribution of this paper is that we have this uh script a python script where you can explore the parameter space. So you can say okay I want to support that many signatures and the tree to look like this and then it's spits out the signature size verification time etc. And we also have tables in in the paper that [snorts] uh do show some of these values already for the parameters that we that we pick.
(55:04) So like explore the parameter space and then next what um what is the next step there is implementations um >> and benchmarking. >> Yeah. >> Yes. Implementations and actual benchmarks. we just estimate through some crude proxy what the performance would be but um we haven't really measured actual performance and at least from my experience implementations usually they inform specifications quite a bit because you find things that you wouldn't notice just going from the from the research direction and uh it's nice that actually there are
(55:48) people actively participating ing in that regard. And also on the mailing list, there were several posts of uh people trying to implement hashbased schemes uh either swings plus or sphinx plus with lower number of signatures. Now they're also looking at possible modifications that we also discussed in this paper and I think this will significantly help with the with the decision uh that that we will have to make.
(56:18) So, uh, yeah, I think that's very good to point out because they have really, so there specifically I want to give a shout out to Conduition. He wrote this awesome blog post where he optimized hashbased signatures like crazy. It's certainly worth worth a read. Um but for the for the bigger discussion, how do we actually migrate um now that this this research um exists um or even before that just with the standardized NIST schemes? Um so one thing that could happen that is uh uh I think a relatively reasonable upgrade
(56:58) path that unfortunately does not have a catchy name. I think so. Matt Corell, he was the first one to uh popularize it on the on the mailing list, but uh others I think have discussed it before, which is um let's say we just introduce a uh a hashbased signature op code like check sick verify that we have for uh for um our curve elliptic curve based signatures.
(57:32) We just introduce one for hashbased signatures. Doesn't matter how it how it looks like something like that. And what people could do today already um wallets wallets could do generate a postquantum public key a hashbased public key and then add this public key along with this new op code in a taproot uh Merkel tree that already exists.
(58:00) Um, so this would be a soft fork. So we add this op code and there's no cost for a wallet except implementation complexity to add this additional spending path if they already use tap routt to the uh the tap routt tree and um so they do that and of course tap routt itself is not secure. So the full tap routt not secure against uh a break of the elliptic curve because we have these key spins as well which just uh require a uh an elliptic curve shore signature um for the public key that is directly in the output. So that's a
(58:42) keypad but there's also the the tap routt tree. Now uh what our colleague uh Tim Roofing at Blockstream proved is that um tap routt uh the tap routt script spence. So the the the Merkel trees inside the tap routt they are still secure even if a quantum computer arrives a cryptographically relevant quantum computer.
(59:10) So what you can do is at a certain point you disable the key spends from taproot and then you still hopefully many wallets have done that they have um these additional postquantum public keys in the tree so they will be able to spend those coins with a hashbased uh signature and the advantage of this is you can use taproot as you do right now.
(59:39) You have these very official key spins, you have the tempered pad, you have music, frost, whatever. Only once the Bitcoin community does this upgrade to disable uh key spans, hypothetically, uh then you need to use uh these new script paths in the Merkel tree in the tab tree >> and this >> this will be one variant. actually very important um benefit of uh kind of bitcoin system in that regard is that uh for example other systems that we're looking like I don't know TLS or whatever uh a lot of time we want encryption and people that are also
(1:00:23) scared of quantum computers today they're also worried about this attack called store now decrypt later >> so they also urging the migration in terms of encryption. So for example, now the post quantum is called encapsulation mechanism that help you to actually encrypt your messages and uh encrypt your communications are already getting deployed while the signatures can wait a little bit later because for most use cases you are scared of your signatures broken up.
(1:00:58) you don't care if they I don't know they see your public key that you don't use anymore 10 years later and so this uh scripting part that you described exactly we can migrate closer when we see the actual thread while the solution is already there you just want to use the solution when when we are actually needed >> and this may be a dumb question, but uh Jonas, you mentioned like Musig and Frost.
(1:01:32) Is there a way to just leverage those on top of like your your private public key pair to harden that >> private key even more from a quantum attack? Does that make sense? >> Even just like obscure like the spending conditions like make it harder >> without introducing uh hashbased signatures or any postquantum assumption.
(1:01:55) just >> use no >> no >> the the the problem is that in whenever the adversary sees a public key they can run their quantum computer and compute the the the private key that's uh corresponding to it. So music or frost or any obfuscation attempts like this will will fail. >> Okay, that's good to know. Fascinating stuff.
(1:02:24) So, what are the dangers if we move too fast on this? I mean, you mentioned them earlier with like if we cuz that's what I worry about was the uh the most disheartening thing about the conversation last week. I think it's good that the conversation's happening, but the idea that the community of developers working on Bitcoin haven't been thinking about this.
(1:02:45) Obviously, you two spent a lot of time on your research. Blockstream does a ton of research and there's plenty of others outside of your organization working on this stuff. What I worry about most is I agree. I think we should want Bitcoin to be as secure as possible. And if the threats of quantum computing or even classical uh uh elliptic curve breaking computers are to manifest, we should prepare for this.
(1:03:10) But um what could be just as dangerous as moving too fast, right? And so trying to have a level-headed discussion about what to do. And obviously you can't use the fear of moving too fast uh forever because then you're complacent. But there's this sort of trade-off between urgency and complacency. Um how do you view it? >> I think it's I mean first of all, yeah, there's a lot of value in the Bitcoin protocol being as simple as possible.
(1:03:44) Um uh because yeah we we want Bitcoin to be secure and that requires a relatively simple protocol. Whenever we add something to Bitcoin there is a risk. Uh I think adding a hashbased signature scheme to Bitcoin I think that risk is manageable but still it will require resources to maintain it to make sure that it's uh that the uh versions are all compatible with each other and there are no consensus relevant issues which is a specific that a problem that is specific to Bitcoin.
(1:04:20) It doesn't exist in non blockchain or non- consensus um systems. So there's a risk in that and then if you add something and no one uses it, uh I think that's just a lot of wasted effort. But I also don't think right now looking at the discussion uh on the mailing list and people I had in person even on Twitter, I don't really think that it is realistic that we will have a uh a postquantum upgrade very soon in in Bitcoin. is at least my my impression.
(1:04:55) Uh and as you said yeah we want to explore yeah in full what are our options and uh as we said before uh the next uh topic would be to to look at latest based uh how they affect what are the assumptions what are the benefits and doing a proper comparison of what what are the options gives us uh I guess the best the best outcome here.
(1:05:24) So rushing it uh also like this with the figure in the ice is also not not the best way to go. >> No. And again, who knows? That's that's the thing about this quantum uh risk is it's hard to know. It's like a big unknown. It's like climate change almost where it's like it's just around the corner, but it's been said for some time and obviously there are some advancements.
(1:05:49) But again, as a layman, it's not easy to understand where the signal in these advancements are. and talked to some quantum physicists, they say to your point like this doesn't scale linearly. You need more um physical cubits to create logical cubits and if you need thousands of logical cubits to attack Bitcoin, it's an exponential amount of physical cubits is the way I understand it.
(1:06:14) I'm speaking out of my ass. But >> yeah, I mean, if if I may uh if I if I'm allowed to to uh um tell a personal anecdote, I actually I studied cognitive science for my bachelor, which is right at the intersection of AI and human intelligence. And for my masters, I studied computer science with a focus on artificial intelligence.
(1:06:37) If I had told anyone that I believe we would have CHP3 by 2022, they would have ridiculed me forever. At that time, people uh they not not only that they thought maybe I think one of or a [snorts] lot of people thought that something like CH GP3 would never be possible. It's just so much intelligence coming from a machine.
(1:07:05) And look at where where we where we are. Uh now I actually sort of thought when I studied this I thought ah this AI stuff is going no nowhere. It's not not going to be a breakthrough. I'm I'm focusing all my time on on Bitcoin back when I was was a student. Right? So I am just very skeptical of people.
(1:07:28) Oh, I first of all I want to say of course this analogy fails in many ways quantum computing very different to AI of course but uh I am skeptical of people saying or confidently claiming there's no clear path towards a a cryptographically relevant quantum computer. Maybe there's not one right now but I think there could be one any any time.
(1:07:51) >> Yeah. And you have to prepare. If you don't prepare and then suddenly you find out you were wrong. >> Yep. Yeah. >> No, that's it goes back to like measuring and uh balancing complacency versus urgency. Um because again to my point like I think this is a discussion that's been taken seriously for for many years now.
(1:08:20) Um and this like rush to to fix it right now. It's like whoa. Hey, there's good conversations going on. There's good research being done. Let's make sure we get this right because it's critically important. >> Um, >> and on that note, I want to thank you gentlemen, not only for joining me, but for um doing the research on this subject and coming to to explain it to everybody.
(1:08:41) It's been incredibly illuminating for me. Uh, and again like I said earlier, a lot of people take for granted um the technical details of the Bitcoin protocol. it just works for them at the end of the day due to um the work research that individuals like yourself and other developers have done and it's pretty insane sci-fi tech once you look under the hood and trying to upgrade that tech is uh is not an easy feat especially when you have a distributed protocol and you need coordination uh between all those individual actors within the system.
(1:09:19) Yes. But one one thing I want to add there um is that what we're doing is also not rocket science in the sense that it's impossible to understand or anything like that. >> Um because there's also this impression that I see sometimes on on Bitcoin that there is this closed group of perhaps Bitcoin core people, high priests or whatever.
(1:09:46) Um, if that is the case, then that is very bad and I think everyone in the Bitcoin community agrees that would be very bad. Well, we want to have a system based on merit and there's no secret knowledge that needs to be obtained to be part of any sort of group. At least this is the the the system uh uh we we want to have and we want to have the best people working on on Bitcoin.
(1:10:11) And this was also our intention writing this paper. We tried to give a good introduction into this hashbased solution right >> and slowly building up from very basic yes >> from lamper signatures which probably we will not use but just to build the intuition. >> So go take a look at the at the paper. We're trying to introduce this stuff slowly there and moving on and on and showing what are the solutions, what are the trade-offs, what can be done and yeah >> let's have a discussion >> and uh if I can read your research have a conversation with you and know enough to
(1:10:53) like understand what's happening in the background with like verification signature verification and its effect on the protocol anybody can do it. Uh, I think that's uh that's to say the least. But gentlemen, any uh any parting notes? Anything um that you want to leave the audience with right before we wrap up here? I think I would encourage further discussions uh more technical discussions uh reading do what we done doing your own stuff suggest and yeah this is let's uh have it with a good pace not rushing but also
(1:11:35) not not putting it away and saying like yeah this will never happen. >> Yep. I I agree. I mean, there's uh there's still a lot of uh feedback that would be interesting for us in particular from from uh wallet developers. um that that is sort of an an open question how um if maybe there are one developers for example that can deal with a state issue and we have a we have a scheme that we describe which is very efficient um if you can hold state securely.
(1:12:14) So um that will be interesting feedback. Then there is this this benchmarking question um especially with respect to siding on on low powered devices and uh yeah I think those those were the the the the main open questions and the big question is like what is the most interesting parameter set to choose from from the set that we provide and um uh then there's also the question I think some people would also argue that just using the standard uh versus our uh optimized thing would um would uh would be preferable because then it would be supported by uh the um
(1:12:59) secure element on your iPhone or whatever. Um so so that is I think also one of one of the big open questions with respect to hashbased signatures specifically. Could you propose a new standard and get it? >> Uh I mean we could propose but >> would it be accepted is the uh >> the bigger question. >> I we make our own standards right we have the BIPS process and maybe we can get Apple to adopt our standards.
(1:13:31) That would of course be uh the most preferable path. >> Yeah. Well gentlemen thank you. This was uh again incredibly illuminating. Thank you for your work and uh hopefully we can do this again. Maybe uh when you finish your research on lattis space >> signatures, we can uh we can catch up then or maybe not.
(1:13:53) Maybe we won't have to wait that long. But thank you and um I hope you guys enjoy uh the end of the year here. Thank you for for joining me so close uh to Christmas and the holidays. So uh this was awesome. >> Yeah. Thank you very much. It was fun. >> All right. Peace and love, freaks.
