BIP361: Post Quantum Migration and Legacy Signature Sunset#1895
BIP361: Post Quantum Migration and Legacy Signature Sunset#1895jlopp wants to merge 2 commits intobitcoin:masterfrom
Conversation
| | 3 years after BIP-360 implementation. | ||
| |- | ||
| | B | ||
| | At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys. |
There was a problem hiding this comment.
I'd be interested an expanded rationale for the approach of rejecting transactions that rely on ECDSA/Schnorr keys vs freezing quantum vulnerable outputs.
Bitcoin's current signatures (ECDSA/Schnorr) will be a tantalizing target: any UTXO that has ever exposed its public key on-chain (roughly 25 % of all bitcoin) could be stolen by a cryptographically relevant quantum computer.
The approach you propose would definitely prevent more thief long term. What is the delta between this and freezing all quantum vulnerable outputs in terms of vulnerable bitcoins?
Is the mechanism to determine if a transaction is reject, if OP_CHECKSIG appears in the script?
If someone did a Schnorr CHECKSIG and a PQ signature CHECKSIG_ML, would that be rejected? Probably right, that would be the more simple check.
There was a problem hiding this comment.
Added more details to say reject any of the checksig opcodes. I suppose the logic could be "reject all checksig opcodes unless there is also a checksig_ml opcode" if we felt like someone might footgun their funds.
There was a problem hiding this comment.
That's a good approach since you can still have Schnorr OP_CHECKSIG tapscripts in tapleafs without breaking OP_CHECKSIG_ML tapscripts.
This would break OP_CAT based covenants since they use OP_CHECKSIG in a quantum safe way to verify the txhash of the transaction on the stack. This suggests that if we want OP_CAT, we probably also want OP_PUSH_TXHASH so that people don't use OP_CHECKSIG for covenants.
Not necessarily. Operating quantum computers costs a lot. For example no one will run computations if it costs 100M to break 50M worth UTXO. Of course with technological and algorithmic improvements the cost of breaking a key will go down. But as costs go down each quantum-computer owner is faced with dillema, they:
Due to game-theory we can expect quantum-computer-owners to go for option 1. They won't go for option 2, because they don't know if other players will also go for option 2. It introduces race-to-the-bottom dynamics between competing players in which cost-to-break-UTXO approaches value-of-the-UTXO. Does it seem similar to something? Yeah, bitcoin mining in which average-cost-to-mine-one-bitcoin approaches value-of-one-bitcoin. Quantum UTXO hacking can be framed as another parallel process of proof-of-work mining, but with the quantum-computers instead of SHA hashing chips. And as such I don't think it is something to deem negative. |
If the threat were real (super-positional whether it is or not), that is the incentive. Forced movement is a non-starter, ones desire to quantum-proof their key does not impart a responsibility on anyone else. |
|
No one can be forced to move their coins to quantum safe signature schemes. On the flip side, no one can be forced to accept coins from quantum vulnerable signature schemes. |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks, this looks great for a first showing. There are a few minor editorial details I noticed, and one aspect regarding BIP 360 (which I see that Ethan also pointed out).
If you receive abandoned coins that you suspect were stolen by QC, you can burn them. No one is forced to honor them. You're not afraid people will be forced to accept coins, but that they will happily accept them. This undermines your previous argument. This is not a technical BIP, it's a vanity one trying to impose a view on the market.
A functional QC would effectively be a winner-take-all coins, candidates in the running to have it already have access to a material number of coins (Google, Microsoft have countless passwords emails 2FA to custodial platforms and password managers containing seeds, backdoored OS's, softkeyboards... etc). A QC could also sign for any software distribution as it could bitcoin keys, enabling untold new backdoors into systems. There's no change to Bitcoin that can protect Bitcoin from a QC threat (hoax) because Bitcoin is not the only link in the chain. |
Quantum sweeping does not generate consensus, it only funds quantum. Quantum computing isn't bad in itself, it will advance material science far beyond what can be done with classical supercomputers. But it's a mess for everyone if it ends up crashing crypto in the process, so it's better to close as much of the surface of attack as possible to make sure we don't end up with wicked incentives. |
There is no way to know, those transactions are indistinguishable from legit ones, the attacker is literally signing with your private key.
A functional CRQC will be expensive ($1B-$10B) and only break a finite number of keys per year, it's not infinitely powerful which means that their use will be driven by incentives. The Bitcoin community must decide if they want to be the exit liquidity of quantum computing companies. This BIP proposes a way to reduce the surface of attack as much as possible.
A lot of links in the chain have started upgrading. |
|
I read about your BIP on CoinDesk. It's mind-blowing and thank you for leading the way. Post-quantum migration should be pro-active rather than reactive. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
Please keep the comments focused on technical review -- thank you. |
There was a problem hiding this comment.
'''Phase A''': Disallows sending of any funds to quantum-vulnerable locking scripts…
'''Phase B''': Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs.
This BIP is hostile for the Bitcoin community and the entire Bitcoin network because it is saying that you can't spend in the future non-quantum compatible funds.
I think @jlopp also need a disclamer, see: https://qb.tc/team
Simultaneously, this BIP is hostile for quantum capable adversaries because it is saying that you can't steal bitcoin with your fancy computer.
When I wrote my initial essay 4 months ago I was not collaborating with anyone. This BIP is a continuation of those same ideas I came up with independently. |
NOTE: As a miner starting in November of 2013 who has invested more into the ecosystem than most... When I invested in the QBTC team (Great team all Bitcoiners by the way) it was because we agreed with Lopp essay and we reached out to collaborate. Q-day is coming sir and Lopp proposal is the best I have seen and should be supported. |
|
Openly saying that we can't spend in the future non-quantum compatible funds, is hostile for the Bitcoin community and the Bitcoin network! If I have Bitcoin from 2011, I will not able to spend it in the future or receive Bitcoin to my address? |
|
I've attempted to remove the ad hominem and replies to it. @1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw, there's no need to repeat the same argument. Let's keep discussion here focused on technical review of the BIP itself. |
|
@jonatack he proposed nothing technical in nature. He just want us to not able to spend our Bitcoins in the future. I find not a single technical proposal in this BIP draft. |
False. In the event that quantum computers become a reasonable threat, I want people not to be able to spend their coins in a manner that is indistinguishable from quantum theft. As such, I want spending restricted so that it requires a quantum safe cryptographic proof accompanying it. |
|
You don't have to restrict any spending! That is just absurd. You should instead just propose hybrid addresses that are quantum resistant and also backwards compatible with ECDSA. I also don't understand what is this rush. You seem like someone who very much would like to enforce on us the "spending restriction". Quantum computers would need ≥ 1 million physical qubits and this must be logical qubits (error-corrected). We are very-very far from any quantum computer that would pose a threat to Bitcoin. Estimates suggest this kind of quantum computers would exist after the year of 2040. So don't need to rush and block transactions now just because you're afraid of imaginary quantum computers. |
This BIP has no intention of addressing the separate issue of what post quantum cryptographic scheme to implement.
This BIP has no intention of addressing the separate issue of when to implement a post quantum cryptographic scheme. This BIP only addresses the migration and incentives issues that arrive AFTER those questions have been resolved. In short, it sounds like you have not comprehended the actual timeline and preconditions of activating this BIP. |
|
You're free to propose a BIP to compete with BIP-360 and then we'd evaluate how it would affect the need for this BIP. |
|
I strongly consider it. |
|
@jlopp Will send it now to the mailing list before opening a new PR. |
|
@1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw and @pldallairedemers: The scheme you are discussing is orthogonal to this proposal. In this PR, please focus on technical review of the document proposed here. |
|
Banned @1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw for 7 days for continuing to be off-topic after warning. In this PR, please contribute technical review for this proposal. Whether the proposal should be adopted by the community is a separate conversation that is not on-topic here. |
bip-post-quantum-migration.mediawiki
Outdated
|
|
||
| This proposal follows the implementation of post-quantum (PQ) output type (P2QRH) and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will certainly lose access to your funds, creating a certainty where none previously existed. | ||
|
|
||
| '''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types. |
There was a problem hiding this comment.
It should be non-standard, instead of being entirely blocked. Because OP_CHECKSIG can still remain useful, if you will do something more, than just <pubkey> OP_CHECKSIG. For example: if you use OP_SIZE on top of some DER signature, then you won't spend it, without also breaking SHA-256. By knowing a private key to secp256k1 point with one-byte x-value, you can go from 60-byte signatures into 40-byte signatures. But going further will require grinding SHA-256 hashes, which may be harder for quantum devices, than it is for classical ones. See also: https://bitcointalk.org/index.php?topic=5551080.0
|
|
||
| '''Phase A''': Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of P2QRH address types. | ||
|
|
||
| '''Phase B''': Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day roughly five years after activation. |
There was a problem hiding this comment.
It should be timelocked, and that timelock can be many years into the future. It could be also expressed as some future block number. Timelocking is better than burning, because then, future adjustments can be made as soft-forks, instead of being hard-forks. Also, in the meantime, people with frozen funds can still make second-layer transactions, protected by quantum proofs, to change on-chain coin ownership, without making any on-chain transactions, for the time when funds will be frozen. And then, the last coin owners could make a valid on-chain transaction, with classical ECDSA signature, and with quantum proof, that the whole chain of quantum signatures is correct.
|
|
||
| '''Phase B''': Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day roughly five years after activation. | ||
|
|
||
| '''Phase C''' (optional): Pending further research and demand, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, potentially via ZK proof of possession of a corresponding BIP-39 seed phrase. |
There was a problem hiding this comment.
Legacy UTXOs should be moved in exactly the same way as they are today, to let old nodes understand it, and follow the heaviest chain in a backward-compatible way. New quantum commitments can be stored in the witness space, or some kind of second witness (which I call "commitment"). Existing non-quantum nodes should not process any quantum data at all, just like non-Segwit nodes don't know anything about witness space in Segwit transactions. For each and every OP_CHECKSIG call in any existing form, there should be a valid commitment, which would be processed only by upgraded nodes. It would also let some new quantum schemes to compete more fairly with others, because then, the size of the quantum proof is not restricted by the current max block size limit, and can be changed by a future soft-fork, if needed. For example: instead of 4*legacy+witness, it could be factor*(4*legacy+witness)+commitment.
|
Hey @jlopp, beside the currently open feedback, how do you perceive the status of your draft? Are you still planning changes or hope to get more feedback about specific aspects of it? |
This comment was marked as off-topic.
This comment was marked as off-topic.
I think it's stabilized for the forseeable future; expecting more tweaks as other proposals are created / modified and as R&D on quantum safe recovery schemes progresses. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Please focus on technical review. Co-author choices, author backgrounds, and promotion of other proposals are not on-topic here. |
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
I may have overlooked it, but there doesn't appear to be much discussion in the current draft of the soft forks involved here, apart from quite succinctly in the last section on Backward Compatibility and in the sentence on line 28 in the Abstract that mentions a flag day.
Might it be helpful to discuss and specify these forks more in the Specification section and/or in a Deployment section? (See those of other soft fork BIPs for examples.)
My impression has been that this draft excels in communicating context, but is light on the Specification and Deployment(s) involved.
|
The assertion that '''quantum algorithms are rapidly improving''' is misleading. The specific algorithm that jeopardizes Bitcoin's cryptography, Shor's algorithm, has been a known entity since the 1990s and has not undergone fundamental change. This BIP proposal strikes me as highly alarmist and unprofessional. Moreover, it appears to have bypassed the essential, consensus-driven process of the Bitcoin Development Mailing List, as I have not observed any discussion indicating this proposal was ready for a formal pull request. Note: I am an author of a competing draft BIP presently under review on the mailing list. |
The algorithm here is referring to underlying algorithms that make the QC hardware more effective and require fewer physical qubits for a factoring task. Shor's algorithm requires a certain number of logical qubits to perform a task in a period of time. The hardware provides a certain number of physical qubits, so the question then becomes how many physical qubits are needed to make a logical qubit and thus how many physical qubits are needed to run Shor's algorithm attack on a particular key size. We are seeing rapid progress in the quantum algorithms that reduce the number of physical qubits needed for a logical qubit and thus accelerate Shor's Algorithm. In the specific of this work How to factor 2048 bit RSA integers with less than a million noisy qubits (may, 2025) which states: "In Gidney+Ekerå 2019, I copublished an estimate stating that 2048 bit RSA integers could be factored in eight That's a 20x improvement. Now as far as I can tell, this specific paper uses a technique that only applies to RSA and doesn't improve on factoring attacks against the elliptic curve cryptography used by Bitcoin. That said, the very fact that we are seeing this sort of rapid improvements in quantum factoring is worrying. |
It seems to me that there are some misconceptions about the BIPs process and the purpose of the BIPs repository. BIPs start as personal recommendations by the authors to the community. The BIPs repository is a central publication medium for collating these author documents in one highly visible location. Generally, it’s preferable if ideas are met with interest and encouragement before they are elaborated into fleshed out submissions, and there are editorial standards to help keep the repository’s content relevant. Other than that, publication basically only hinges on the submission being on-topic and sufficiently mature. As proposals get adopted by the community, the community takes on more ownership of proposals, but especially in the Draft stage and even up to the Proposed stage, BIPs should not be construed as endorsed whatsoever by anyone except the authors and other explicit proponents. For this particular proposal, the mailing list thread presenting the idea for this BIP collected 22 emails and a number of replies indicated interest or support for the idea which absolutely should encourage the would-be BIP author to submit their document to this repository. |
This comment was marked as off-topic.
This comment was marked as off-topic.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
I was just revisiting this proposal with BIP 360 getting close to publication. Given that this proposal is currently not implementable and presumably will not be for quite some time, I was wondering whether it might make sense to read this proposal rather as a potential roadmap to address the quantum threat and categorize it as an Informational BIP.
Also, the preamble would need some tweaks now that BIP 3 was deployed.
|
Let’s refer to this as BIP 361. Please:
|
murchandamus
changed the title
|
Alright, there are still several things I've been wanting to add, just hasn't been a high priority since this is a far-future plan. Will aim to get some updates pushed in the next week. |
jlopp
force-pushed
the
quantum_migration
branch
5 times, most recently
from
8d09db6 to
e706bf7
Compare
jlopp
force-pushed
the
quantum_migration
branch
from
e706bf7 to
de293ff
Compare
|
Made the requested changes though I'm not clear on how to resolve the current failing diff check. |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Thanks for the update. I think I see what the issue is and pushed the fix.
README.mediawiki
Outdated
| |- style="background-color: #cfffcf" | ||
| | [[bip-0361.mediawiki|361]] | ||
| | Consensus (soft fork) | ||
| | Post Quantum Migration and Legacy Signature Sunset | ||
| | Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers | ||
| | Informational | ||
| | Draft | ||
| |- |
There was a problem hiding this comment.
The line with the BIP number is the second number of the BIP!
TBH, I can’t tell you why we color the table, but the line with the background color belonged to BIP 370. :)
| |- style="background-color: #cfffcf" | |
| | [[bip-0361.mediawiki|361]] | |
| | Consensus (soft fork) | |
| | Post Quantum Migration and Legacy Signature Sunset | |
| | Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers | |
| | Informational | |
| | Draft | |
| |- | |
| |- | |
| | [[bip-0361.mediawiki|361]] | |
| | Consensus (soft fork) | |
| | Post Quantum Migration and Legacy Signature Sunset | |
| | Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers | |
| | Informational | |
| | Draft | |
| |- style="background-color: #cfffcf" |
12 participants
Initial draft of a proposal for how to incentivize migration to post quantum cryptography and safeguard the ecosystem from unnecessary inflation of the circulating supply and the economic turmoil likely to accompany such an event.