Is the proposed BIP 360 the correct way to achieve quantum attack resistance?

[d5000]

Just today I stumbled upon the proposed BIP 360. It is still not an "official" BIP and was published as a draft by a developer Hunter Beast in December 2024. It seems to be part of a project called QuBit, which will propose more related BIPs in the future.

The BIP proposes a new output type, Pay to Quantum Resistant Hash (P2QRH). Basically, you could create a new set of quantum resistant addresses starting with bc1r. Initially, the FALCON algorithm would be supported, but later support for lighter algorithms would be added, once they are tested enough.

FALCON signatures are 10 times larger approximately than ECDSA signatures and 20 times larger than Schnorr signatures, so this would impact block space if it becomes popular. In addition, it would take over 70 days to transfer all existing UTXOs into P2QRH outputs. So if such a proposal comes too early, it could also have some negative consequences like block congestion, which could exceed the Ordinals Inscriptions wave from 2023. Perhaps a lower weight could be assigned to these signatures.

The BIP is also discussed in the developer mailing list, see here for example.

What do you think? Is this the best way to introduce quantum safety in Bitcoin?

In my opinion it's a quite simple and straightforward approach. However, I don't know if hard-coding the algorithms into the Bitcoin code is really the best way to implement it, because we don't know which algorithm is the best. Years ago there was a proposal to introduce the Simplicity script language instead, which could be used to implement algorithms without hard-coding them (see e.g. this short explanation by Adam Back).

[achow101]

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.

[stwenhao]

Is the proposed BIP 360 the correct way to achieve quantum attack resistance?

I guess not.

The BIP proposes a new output type, Pay to Quantum Resistant Hash (P2QRH).

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.

FALCON signatures are 10 times larger approximately than ECDSA signatures and 20 times larger than Schnorr signatures, so this would impact block space if it becomes popular.

Yes, enforcing a proposal, which wouldn't be jpeg resistant, would be hard in practice.

Perhaps a lower weight could be assigned to these signatures.

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

What do you think?

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).

Is this the best way to introduce quantum safety in Bitcoin?

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.

However, I don't know if hard-coding the algorithms into the Bitcoin code is really the best way to implement it, because we don't know which algorithm is the best.

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.

[d5000]

I think that's a bad idea as expecting users to understand the tradeoffs between different cryptosystems is fundamentally untenable.

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.

It does not solve the problem of existing UTXOs.

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.

Yes, enforcing a proposal, which wouldn't be jpeg resistant, would be hard in practice.

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.

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.

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?

[stwenhao]

And one can also argue that the existing P2PK/P2MS etc. UTXOs shouldn't be touched at all.

Some people disagree with that: Against Allowing Quantum Recovery of Bitcoin

I guess that means that arbitrary data could be stuffed into these signatures?

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:

Is there any alternatives to replace  ECC?

|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Name        | PrivK |  PubK |   Sig | Security |  PubK |   Sig | block |  average |
|             | bytes | bytes | bytes |     bits | *secp | *secp | *secp | block MB |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| secp256k1   |    32 |    32 |    64 |      128 |   1.0 |   1.0 |   1.0 |      1.3 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| RSA 2048    |   512 |   256 |   256 |      112 |   8.0 |   4.0 |   6.0 |      7.8 |
| RSA 3072    |   768 |   384 |   384 |      128 |  12.0 |   6.0 |   9.0 |     11.7 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Dilithium2  |  2528 |  1312 |  2420 |      128 |  41.0 |  37.8 |  39.4 |     51.2 |
| Dilithium3  |  4000 |  1952 |  3293 |      192 |  61.0 |  51.5 |  56.2 |     73.1 |
| Dilithium5  |  4864 |  2592 |  4595 |      256 |  81.0 |  71.8 |  76.4 |     99.3 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Falcon-512  |  1281 |   897 |   666 |      128 |  28.0 |  10.4 |  19.2 |     25.0 |
| Falcon-1024 |  2305 |  1793 |  1280 |      256 |  56.0 |  20.0 |  38.0 |     49.4 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|
| Sphincs+    |    64 |    32 |  7856 |      128 |   1.0 | 122.8 |  61.9 |     80.5 |
| Sphincs+    |    96 |    48 | 16224 |      192 |   1.5 | 253.5 | 127.5 |    165.8 |
| Sphincs+    |   128 |    64 | 29792 |      256 |   2.0 | 465.5 | 233.8 |    303.9 |
|-------------+-------+-------+-------+----------+-------+-------+-------+----------|

Looks also interesting but wouldn't this make transactions even heavier?

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.

[cygan]

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

[Wind_FURY]

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.

[Satofan44]

And one can also argue that the existing P2PK/P2MS etc. UTXOs shouldn't be touched at all.

Some people disagree with that: Against Allowing Quantum Recovery of Bitcoin

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. 

I posit that the corollary to this principle is: Your keys, only your coins.

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?

Imagine, for example, being James Howells, who accidentally threw away a hard drive with 8,000 BTC on it, currently worth over $600M USD. He has spent a decade trying to retrieve it from the landfill where he knows it's buried, but can't get permission to excavate. I suspect that, given the choice, he'd prefer those funds be permanently frozen rather than fall into someone else's possession - I know I would.

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.

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

Interesting, let's see what others have to say about it and whether it has any chance of acceptance.

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.

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.

[Mr.leeemzy]

Just today I stumbled upon the proposed BIP 360. It is still not an "official" BIP and was published as a draft by a developer Hunter Beast in December 2024. It seems to be part of a project called QuBit, which will propose more related BIPs in the future.

The BIP proposes a new output type, Pay to Quantum Resistant Hash (P2QRH). Basically, you could create a new set of quantum resistant addresses starting with bc1r. Initially, the FALCON algorithm would be supported, but later support for lighter algorithms would be added, once they are tested enough.

FALCON signatures are 10 times larger approximately than ECDSA signatures and 20 times larger than Schnorr signatures, so this would impact block space if it becomes popular. In addition, it would take over 70 days to transfer all existing UTXOs into P2QRH outputs. So if such a proposal comes too early, it could also have some negative consequences like block congestion, which could exceed the Ordinals Inscriptions wave from 2023. Perhaps a lower weight could be assigned to these signatures.

The BIP is also discussed in the developer mailing list, see here for example.

What do you think? Is this the best way to introduce quantum safety in Bitcoin?

In my opinion it's a quite simple and straightforward approach. However, I don't know if hard-coding the algorithms into the Bitcoin code is really the best way to implement it, because we don't know which algorithm is the best. Years ago there was a proposal to introduce the Simplicity script language instead, which could be used to implement algorithms without hard-coding them (see e.g. this short explanation by Adam Back).

In my opinion It is a bad idea, too soon or not safe to introduce quantum to Bitcoin already because of some negative challenges like "how the transfer of all existing UTXOs into P2QRH outputs would take over 70 days before it is successfully done/completed and have some negativity to Bitcoin like blockage of congestions if it's exceeds the original inscription wave from the past" as you mentioned above and with the high expectations and trust many people have in the Bitcoin world it will be a disadvantage to the Bitcoin world with people having issues or loosing trust in the Bitcoin network. So I suggest before introducing quantum to Bitcoin all the above facts and challenges should be worked on to avoid negative impact to the Bitcoin.

[ABCbits]

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

It's merged, although the BIP status is still "Draft". So there's possibility some details may be changed.

While this proposal does not include the introduction of post-quantum signature schemes, we think it's worth commenting on security considerations related to this possibility.

Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different levels of protection and should be scrutinized before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin and encourage others to engage in this research as well.

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.

--snip--

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.

Does it matter? i expect most altcoin would be dying before quantum computer is mature enough to break cryptography usually used on those altcoin.

[Wind_FURY]

--snip--

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.

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.