bitcoin-dev

Combined summary - Trivial QC signatures with clean upgrade path

Combined summary - Trivial QC signatures with clean upgrade path

The recent discussions on the Bitcoin Development Mailing List have delved into the complexities of enhancing Bitcoin's security framework in anticipation of quantum computing (QC) threats.

The contributors have highlighted several innovative proposals, ranging from integrating Winternitz one-time signature algorithms (WOTS) to exploring Proof of Quantum Capability (PoQC) as methods to transition towards post-quantum (PQ) cryptography. These discussions underscore a proactive approach in safeguarding Bitcoin against potential quantum computing breaches, with an emphasis on flexibility and gradual implementation of PQ cryptographic solutions.

A significant portion of the debate has centered around the dilemma of initiating protective measures against QC threats without prematurely committing to specific changes that might become unnecessary if QC developments do not materialize as expected. Matt Corallo introduced the idea of a post-quantum fallback key and a consensus level proof of quantum computer (PoQC), aiming to minimize the activation impact of forks in response to QC threats. This involves monitoring for transactions that could indicate the breaking of cryptographic assumptions by a QC, triggering changes in consensus rules. Further discussions also explored the mitigation of coin loss or theft following a QC breakthrough, suggesting soft fork restrictions on key path spends or introducing new output types immune to QC attacks while maintaining backward compatibility.

In another thread, Tadge Dryja and Anthony Towns discussed the preemptive integration of PQC options into wallets to secure funds against future QC threats. This strategy aims to mitigate risks associated with delaying PQ protection until it becomes an immediate necessity, potentially leaving many funds vulnerable. The dialogue acknowledged the speculative nature of certain aspects of this strategy, particularly regarding the technical specifics of future quantum computers and the crypto assumptions required for hard-fork spend-via-future-PQC-proof-of-knowledge approaches.

Furthermore, the conversation shifted towards the potential challenges of implementing "OP_SPHINCS" signatures within the Bitcoin protocol due to their large size, which could significantly impact the number of inputs per block. This raised concerns about finding alternatives with smaller signature sizes or increasing block sizes to accommodate these larger signatures. The discussion also critiqued the idea of preemptively adding secret spend paths for OP_SPHINCS, highlighting the potential risks involved without clear benefits.

Moreover, there was a focus on not waiting for the introduction of new script opcodes like OP_CAT due to prolonged deliberation and uncertainties related to Miner Extractable Value (MEV) and Bitcoin's development trajectory. A recommendation for wallet developers to begin integrating dedicated opcodes for smoother adoption was made, emphasizing the importance of preparing for quantum computing advancements while navigating operational challenges.

Lastly, the update on post-QC script path in Bitcoin's development, which does not require a softfork for commitment, suggested immediate actions for wallets to start integrating this fallback mechanism. However, the security of the post-QC script must be equivalent to that of a private key, presenting particular challenges for hardware wallets.

The collective discourse reflects a multifaceted approach towards incorporating quantum-resistant cryptographic measures within Bitcoin. By exploring various cryptographic and strategic solutions, the Bitcoin development community is laying the groundwork for a secure transition to post-quantum cryptography, ensuring the longevity and resilience of Bitcoin amidst emerging technological threats.

Discussion History

0
Matt CoralloOriginal Post
December 15, 2024 21:42 UTC
1
December 15, 2024 23:54 UTC
2
December 16, 2024 01:30 UTC
3
December 16, 2024 01:40 UTC
4
December 16, 2024 11:14 UTC
5
December 16, 2024 15:57 UTC
6
December 16, 2024 22:20 UTC
7
December 17, 2024 05:31 UTC
8
December 18, 2024 03:29 UTC