Is BIP 360 the right move for quantum attack resistance?

Today, I came across the proposed BIP 360. It isn't officially recognized yet and was shared as a draft by a dev named Hunter Beast back in December 2024. Apparently, it's part of a project called QuBit, and they plan to suggest more related BIPs down the line. This BIP is about a new output type called Pay to Quantum Resistant Hash (P2QRH). The idea is to create a new batch of quantum-resistant addresses starting with bc1r. At first, it supports the FALCON algorithm, with plans to add support for lighter algorithms later on, once they've been sufficiently tested. FALCON signatures are about ten times bigger than ECDSA signatures and twenty times larger than Schnorr ones, so if this catches on, it could really affect block space. Plus, migrating all current UTXOs to P2QRH outputs could take over 70 days. If this proposal rolls out too soon, we might see issues like block congestion, potentially worse than the Ordinals Inscriptions surge from 2023. Maybe there's a way to give these signatures a lower weight. There's also some chatter about this BIP on the developer mailing list, check it out here for more info. What are your thoughts? Is this the optimal way to bring quantum safety to Bitcoin? I think it's a pretty straightforward approach. But hard-coding the algorithms into the Bitcoin code might not be the best route since we still don't know which algorithm will turn out to be the most effective. A while back, there was talk of using the Simplicity script language instead, which could allow for implementing algorithms without having to hard-code them.

From what I can tell, Hunter is not a cryptographer, so I take this proposal with a very large grain of salt. It seems though, because he is not a cryptographer, the proposal does not choose 1 signature scheme, but rather gives users the option to choose from many. I think that's a bad idea as expecting users to understand the tradeoffs between different cryptosystems is fundamentally untenable. From a cursory reading, if one of those cryptosystems were broken, user funds could be significantly at risk. This proposal to me seems to be written by someone who strongly cares about quantum security, but is not a cryptographer so went with the classic "we do all these different cryptography things so it must be secure!" There is some discussion about this in this mailing list thread;https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/pIL6rZbtAQAJ including response from a cryptographer and seasoned bitcoin soft fork proposers.

I guess not. It does not solve the problem of existing UTXOs. If you have P2PK, P2PKH, and all other types of addresses, listed in tables from this BIP, then you don't see any explanation, how to distinguish between the real owner, moving some P2PK to a new address type, and some cracker, who just produced a valid signature, maybe even without knowing the private key. Yes, enforcing a proposal, which wouldn't be jpeg resistant, would be hard in practice. That's another thing worth considering. Currently, we have legacy space, and witness space. Maybe all of that additional traffic should be put into yet another place called "commitment space"? I am not sure, but I saw some discussions about it: https://groups.google.com/g/bitcoindev/c/Lpy4Waz07cg I think each and every OP_CHECKSIG call should contain an additional commitment. In this way, it will be compatible with existing system, and it will be also aligned with potential attacks. Another incentive to keep OP_CHECKSIG functionality, is to make it double protected: if new, "quantum-safe" address will turn out to be unsafe for any reason, then there will still be a regular OP_CHECKSIG, keeping coins where they currently are, as long as "quantum alarm" is not yet raised. Also, I think old nodes should not be forced to process new types of commitments, just like legacy nodes are not forced to know about Segwit. Because then, if layers would be clearly separated, it could be possible to soft-fork-out of the faulty quantum-resistant proposal. Some models were broken classically, and I think it is a good idea, to not only have a way to upgrade to post-quantum world, but also to do a downgrade, when needed (for example if a new scheme would allow flooding the chain with a lot of unnecessary, non-consensus data). Definitely not. When SHA-1 was broken, people introduced "hardened SHA-1" instead, and of course, everyone is encouraged to switch from SHA-1 to at least SHA-256 in next versions, but because of backward compatibility, this process is quite slow, at least in Git. And here, I guess it would look in a similar way: someone could find some kind of bug (for example SIGHASH_SINGLE), and use it to break something. But: I guess it won't make the system wide open for arbitrary attacks, but rather would allow a particular way of tweaking single things, like it was the case with SHA-1, or SIGHASH_SINGLE. And then, "quantum-resistant" proposals would address just only that, while also encouraging users, to switch to new address types. Well, we have to pick something, if we want to make any changes. It is easier to take that decision, if you know, how the attack would look like. But if you don't, then it is just a pure guessing. And I think making OP_CHECKSIG more restricted is a better way, also because it was tested in the past (for example when solving malleability issues, by rejecting negative s-values in DER signatures). Here, it would be similar: you would need a regular signature for OP_CHECKSIG, and also some kind of commitment, preferably seen only by new nodes, to not bloat the old ones with features they didn't opt into. Edit: Another test case for output scripts: "<signature> OP_SWAP OP_CHECKSIG". Here, you can use public key recovery, if a signature is a classical ECDSA, and not Schnorr signature behind TapScript. For a given signature, it is trivial to compute a matching public key, and make a transaction, which will spend that kind of output, as long as your signature is valid. If some proposal claims to solve the quantum problem, and can address this example correctly, then it may be worth considering. By the way, note that "<signature> OP_SWAP OP_CHECKSIG" is a Script, which means, that it would be a raw Script, or could be put behind some kind of "script hash". This BIP just claims, that "there is hashing, so we are safe". But I disagree, because of cases like that, and some more scripts, which could be also considered unsafe, if OP_CHECKSIG would be broken.

That's an argument I hadn't thought about, thanks for your opinion, I think I agree. I read a bit further through the mailing list thread and the proposer seemingly left the discussion offended, so my reading is that at least in this state the BIP has no chance to become accepted. I think this is also outside of the scope of a proposal we can do now, in 2025. The idea of BIP360 was simply to provide a migration route. And one can also argue that the existing P2PK/P2MS etc. UTXOs shouldn't be touched at all. Thanks, interesting thread but a bit difficult for me as a non-cryptographer I guess that means that arbitrary data could be stuffed into these signatures? The "commitment space" idea is also interesting. Looks also interesting but wouldn't this make transactions even heavier? Thinking about that however, would it be possible to combine this approach with the CISA approach, e.g. could the post-quantum signatures be also aggregated in this style? Or is this mechanic ECDSA / Schnorr-only?

Some people disagree with that: Against Allowing Quantum Recovery of Bitcoin Yes. For example, in the current secp256k1 implementation, when you have a Schnorr signature, it can take 64 bytes. If quantum-resistant signature would take for example 64 kB (completely broken image resistance), or maybe even 64 MB (completely broken video resistance), then it could be used not only to protect users from quantum computers, but also to store a lot of arbitrary data on-chain. Which means, that the new scheme should not require significantly more resources from node runners. Also, someone already shared, how different models can affect block sizes: Well, that way is compatible with scripts. If we would have only "pay-to-quantum-resistant" addresses, spendable with just a single signature, then it would be similar, as if we would have only P2PK, and nothing else. Which means, that if instead of OP_CHECKSIG, there would be OP_CHECK_QUANTUM, then it would be needed to handle more than a single signature, or to combine some signatures in a "OP_CHECKSIGADD"-ish way, and turn N quantum-resistant signatures into a single one, equivalent to executing N heavy, separated signatures in a sequence, and checking if M of N of them are valid. In other words: people would also need multisig in post-quantum world. And they would probably also need scripts.

two days ago, an updated version of bip-360 was integrated into the official Bitcoin bips repo: https://github.com/bitcoin/bips/tree/master/bip-0360 this new/updated version introduces pay-to-markle-root (p2mk), a new optional output type that eliminates the quantum-vulnerable key path consumption of taproot while maintaining compatibility with tapscript and script trees. this is still a soft fork, so all existing taproot outputs remain unaffected. https://bitcoinmagazine.com/news/bitcoin-advances-toward-quantum-resistance

Will there be a narrative shift in crypto? - A shift that will indicate which blockchains will survive and continue to chug along, producing block after block for decades, and which of those blockchains will be abandoned by their developers because updating their shitcoin networks to achieve Quantum Resistance won't be worth all the effort, and/or because they lack the technical knowledge and skills.

Lopp is generally a short-minded idiot, he is focused only on the $ value of his coins in the short-term because he does not have any other considerable sources of wealth. The good thing about posts like this is that it guarantees that there will be no consensus on freezing versus not freezing, or as he puts is "burning", which means that we will default to not doing anything which is the same as not freezing.  Stuff like this in the post is factually false, nothing really makes keys "yours". I could roll a very lucky dice and generate those keys, does that make them mine now? If not, why wouldn't it? He even quotes this fake story. Overall it is a pretty shitty article by a money-hungry individual who wants to violate the core reasons for Bitcoin's existence. How about instead of doing this, we freeze his coins rather than mine for an arbitrary reason that I find important and that I believe is an existential threat to Bitcoin?  I will never vote yes towards freezing. Fuck you Lopp and fuck anyone else who wants to freeze other people's coins. You exactly like the very pieces of shit that are controlling the centralized systems that Bitcoin was designed to get away from. Interesting, let's see what others have to say about it and whether it has any chance of acceptance. Most layer 1s and layer 2s are completely dead, ghost chains. They don't need the quantum threat to kill them, they are already dead or dying.

It's merged, although the BIP status is still "Draft". So there's possibility some details may be changed. Good to see there's no enforced QC-resistant cryptography on this BIP. So I expect this BIP shouldn't face much resistance, unless there's another technical issue i don't know. Does it matter? i expect most altcoin would be dying before quantum computer is mature enough to break cryptography usually used on those altcoin.

It actually DOES. Have you seen those shitcoin networks with billions in Market Value but are actually flawed? Those developers will continue to scam the plebs and the newbies in crypto if the newbies/plebs don't see how incompetent those developers actually are. The race to Quantum Resistance will take the shift of narrative back to Bitcoin.

I like that approach. It was unexplainable to me that Taproot had this vulnerability having been conceived when the quantum computer threat was already spoken about. And as far as I know, there were only complicated ways to create Tapscripts without that problem. Have changed the OP a bit to reflect the BIP's change. I was wondering why P2MR was even necessary considering the possibility to use simply P2(W)SH. But it seems implementing quantum safe algorithms via TapScript is actually easier/cleaner, due to OP_SUCCESS opcodes. I've briefly mentioned it, but one could simply create a space similar to the Witness field exclusively for quantum signatures, with an even lower weight per byte. I think it would be possible to largely impede to use this field for a purpose which is not the publication of the public key + the signature (it would be difficult to grind these data fields to include arbitrary data).

In the current Bitcoin consensus, you need a public key to spend any coin in a safe way. As long as there is no alternative for OP_CHECKSIG, we have, what we have. Also, if public keys are exposed, then making multisigs is easier, which is also why Taproot keys are not hashed, but just used directly. I think if we would have only P2PK, and we would know, what we know today, then all new address types could be just attached to P2PK, in a similar way, as it is done in P2TR, where you have just some public key in the output, and everything else happens inside the input. If "complicated" means hashing things at least once, then yes, it was "complicated". By the way: the bare multisig works like that: But, nothing prevents people from using hashed public keys instead: So, as you can see, even making multisigs with hashed keys is possible. But of course, it takes more space, and it brings only additional weaknesses, so it was not implemented in that way. Because developers wanted to update the Script. Another reason was to replace ECDSA signatures with Schnorr signatures. However, dropping DER encoding backfired, because OP_SIZE cannot be used on Schnorr signatures that easily, so if you want to lock things on Proof of Work, then you are stuck with P2WSH, because it doesn't work on Taproot, if you don't have new features like OP_CAT.

What do you mean with "know what we know today"? I haven't understood that part still ... I still don't understand why the key-path was really necessary. Articles about the topic cite privacy advantages, for example, but at the same time you introduce a potential bug which could make most P2TR outputs obsolete in a decade or so. According to gmaxwell's post it could be related to that better proposals existed but were much more complicated to implement and thus there was not enough devpower. Thanks for linking that interesting thread by the way The point that the address in P2PWKH actually diminished the security a bit (due to collission risks) wasn't that clear to me before. PS, for those interested in the topic: There's this Delving Bitcoin post where current methods are explained/suggested to make the key path unspendable and thus Taproot scripts which aren't vulnerable to quantum theft (as long as no short exposure attacks are feasible).

Initially, there was only P2PK. At that time, there was no Script, and we had "pubKey" and "sig" in the source code. Then, the Script was invented, and it became "scriptPubKey" and "scriptSig". In the first released version, in 2009, we had P2PK, and P2PKH. It was the first mistake, because there were two types of outputs, and it could be used to trace users, by checking, which address type they picked. You could know, if someone was trading online, and using pay-to-ip, or if someone was an active miner, because then P2PK was used in new coinbase outputs. For offline users, P2PKH was the most popular way of sending coins, because only then, you actually needed to process someone else's address. If someone was online, then your client could just connect with that person, and handle public keys automatically, without showing you any address at all. And then, we had another change, which introduced P2SH as yet another address type. It fragmented the space of addresses even more, because now, some addresses were key-based, and some were script-based. Later, Segwit splitted it even more, by introducing P2WPKH and P2WSH. More address types, and even more data, to compromise someone's privacy. Later, Taproot was created, and after all of these years, people noticed, that as long as secp256k1 is in use, public keys are revealed sooner or later. Hashing only creates a false sense of security, by making some attacks harder, while also making other attacks easier. And for that reason, P2TR is based just on secp256k1 public keys, and everything else is hidden under the hood. But if you know the private key for what you can see in the UTXO set, then you can move a given Taproot output, even if you know nothing about TapScript behind it. You just make a valid Schnorr signature, and you are good to go. So, if we would need to make things from scratch, then we could have just P2PK, and nothing else. There could be just one address type in existence, and everything else could be attached to that. Or rather: such P2PK would be more similar to P2TR in practice. But if you see some public key in the UTXO set, then P2PK and P2TR are quite similar: their inputs are completely different, but their outputs are almost identical: you have just some coin, locked on some public key, and knowing the private key to some secp256k1 point is all you need in both cases. Because it is the only thing, that is verified, when something is never disputed. If you have a single user, self-sending coins, or just making a regular one-user-to-one-user payment, then, you only need a public key, and a signature. Because if you explore the historical data in the blockchain, then you don't need hashes. Knowing, that the hash of some 32-byte public key, is equal to some 20-byte number, is just some redundant information. You never need it. The only thing that matters, is if the signature matches the public key. Hashing is just temporarily hiding things, which are later revealed in plain sight, and which provide no benefit in the historical data. So, if you process some deeply-confirmed transaction, you have a choice: to check (hash,pubkey,signature), or to check (pubkey,signature). Hashed version takes more space, and provides no additional security, because the public key is always revealed in historical data. Also, if you have a public key, and a signature, then you can be sure, that for each public key, there is only one private key. For hashed version, you have 2^96 possible matches on average, so there is some additional weakness, which is not exploited yet, but could be in the future. Hashing things is just delaying the inevitable: if you think, that secp256k1 is unsafe, then it should be replaced with something better. As long as it is the only available option, you don't have a choice. Every coin, which is not trivially spendable by miners, is protected with OP_CHECKSIG, or its equivalent. Also note, what is the difference between P2TR, and P2MR: instead of pegging everything under public keys, things are splitted again, between key-based, and script-based version. So, P2MR will become an alternative for P2SH or P2WSH, and P2TR will be in a similar basket as P2PK, P2PKH, or P2WPKH, by being movable just by a single signature. Which will push us backwards, and bring us back to the times, where things were splitted between key-based and script-based addresses, instead of blending all users behind the same address type, and making it easier to hide in a bigger crowd.

Thanks for your explanation, but I don't know if I agree. Regarding the privacy argument, my interpretation is that the groups using different kinds of addresses, as long as there is no extreme advantage/disadvantage of a single type (as it occurs with P2PK currently which is used almost by nobody anymore), are large enough to prevent someone being "categorized" according to the address type they use. The other privacy problems Bitcoin has (e.g. SPV clients connecting to servers who see all your wallet addresses) and even the general public structure seem much more important to me. I get the problem if we're talking about very specific scripts like atomic swaps, where some types can be "traced" indeed, but output types per se imo do not really bring disadvantages. Of course it would be elegant to have only one type of address. But the quantum vulnerability of P2PK/P2TR seems much more problematic to me than the collissions in the hashing algorithm (see below). I get that in some cases the key-path can be very useful, for example in some complex multisig contracts where later all participants can agree to "just return the output to its original owners" (or whatever base contract they had). My problem is more that there was no really easy way to get rid of the key-path completely. You'd have to use techniques like this NUMS point generation. According to a Google search, disabling key path by NUMS point generation is a very small niche. I get it, but it still seems more important to me that it is a big difference if something can be calculated with Shor's algorithm in a few years (Satoshi's coins) or in 10-80 minutes in the form of a short exposure attack. The quantum threat in this case is a bit different than traditional attacks on cryptography because it's not a technology like traditional Von Neumann computing where we already somewhat know what to expect in the future (due to Moore's Law). And thus we don't know if short exposure attacks ever could become a thing, or if they are fundamentally impossible due to extreme technical requirements for the quantum computers. But long exposure attacks will, with some likelihood, be possible in some years to a few decades, and in this case hashing does make an enormous difference.

It is not limited to just that. In general, spending by key should be the default behavior, when everyone agrees, and nothing is disputed. For example because it is cheaper. And if everyone is online, and everyone agrees, then executing N-of-N multisig is possible, and can be expressed just as a single on-chain signature. So, if you want to know, why P2TR is implemented in that way, and not another, then there is quite simple explanation: if you want to hide complex contracts, and single users, under the same on-chain representation of things, then you will end up with just a single Schnorr signature. Because contracts don't have to be executed on-chain. They can be implemented purely off-chain, and just lead to a single signature, which will enforce it on-chain later. Which is exactly what P2TR is trying to do, by encouraging everyone to spend by key, and discouraging spending by TapScript (for example because it takes more on-chain space, so it is more expensive, but not only that). It is like that by design. Creators simply assumed, that if secp256k1 is unsafe, then everything else also is, no matter if it will be hashed or not. Hashing just delays the inevitable, and creates a false sense of security. Also, it is technically possible to have a chain, where all coins are always mathematically spendable, even if moving some of them may be extremely difficult. But it was not done in this way, and using invalid x-coordinate will lead to burned coins. I think it is a mistake, because then, you can never use the cheaper, and more private path of spending things by just providing a single signature. A basic building block for Taproot should be N-of-N multisig between everyone, who put coins in. Then, if one person disagrees, you end up with the same thing as NUMS point. But then, you keep the option to move coins somewhere else, if everyone will agree on that. Which can be useful, if participants are online, and you can ask everyone about it, prepare a transaction, combine N signatures into one, and move the coins, pretending, that a single person did all of that. Which is yet another reason, why spending by key is the default way. If you want to have N-of-N multisig as a basic building block for any contract, then spending by key seems reasonable. If you strongly believe in hashing, then you can just use P2WSH, and lock coins on Proof of Work. Then, on-chain clients don't have to know anything about your spending conditions, and everything can be done inside some second layer. Also, as long as you have to join the contract, to know the mining key, all outside observers don't even know the exact Script, which is in use. Also note, that breaking secp256k1 alone won't fully break OP_CHECKSIG. It will just make signatures smaller, than they currently are. Part of the ECDSA and Schnorr is SHA-256 hashing. Which means, that by breaking secp256k1, you won't suddenly get 9-byte DER signatures. You will only get 40-byte ones, and going further will require gradually breaking SHA-256. Which is also why I think OP_CHECKSIG shouldn't be completely disabled, unless secp256k1 and SHA-256 will be both obsolete. Which means, that if only secp256k1 will be broken, but not SHA-256, then it will be still possible, to keep OP_CHECKSIG, but to also require some additional proof. And then, old nodes would see all signatures in the same way, as they are made today, but new nodes would process these proofs in a soft-fork way. Old nodes don't have to even receive these things, just like non-Segwit nodes don't know anything about witness data.

I get this, but there is a little difference: the convenience and speed of an upgrade to QC-resistant cryptography. Banks often use SaaS cloud software platforms, or at least quite standardized software. The software vendors can simply upgrade the cryptography and then the platforms would be secure again. And the signature size isn't so much a problem too. On Bitcoin instead, an upgrade potentially can take a lot of time. Not because simply integrating FALCON or some other cryptosystem would be a really big deal, but because all "quantum resistant" protocols have big signature sizes, and thus you will have to try to integrate this in the plan, because if everybody rushes to upgrade from ECDSA to FALCON we would run into a huge block space bottleneck. We would probably need a new Segwit witness discount for these signatures. And have to estimate how high will be the additional blockspace needed for the "transition rush" as a lot of people would like to secure their funds ASAP. Then there has to be decided if there's done something with P2PK and other vulnerable outputs, or not, which can lead to heated discussions and even to a hard fork. So the planning for the post-quantum world is a little bit more complex in Bitcoin. But I agree that it's overdramatized. From today's point of view addresses which were not re-used are safe and there are ways to protect and move them even if a QC exists which can hack a key in 10 minutes. All solutions are on the table, with the exception of P2PK and friends where probably no ideal solution exists, but a redistribution of old "lost" funds would also not kill Bitcoin.

So basically your freakout is similar to miners about next halving? Best,

I heard some wallets already started working on adding bc1z segwit v2 addresses from bip-360 proposal, but thus is still in early development phase. What I don't understand is how adding new type of addresses is going to give quantum protection to bitcoin, unless all bitcoin is moved from old to new addresses?

Freakout? Lol no. I'm only in the camp that "we should plan a bit ahead, but no rush". And BIP 360, in its new iteration, seems a good way forward to me. Only re-used addresses (where the public key was published on chain, i.e. people have spent money from that address) and some special kinds of addresses which are barely used (P2PK, and some P2TR) are vulnerable currently. So it's not that everybody must move. Most people can relax and wait. Once the new addresses arrive, it may be an option for those who hodl large amounts of coins and thus wouldn't be worried about the fees. It has of course to be said that the current BIP-360 does not include quantum-secure cryptography yet (this is a second step and probably years ahead). But they allow to create Taproot scripts without the P2TR vulnerability more easily.