Nic Carter：量子運算距離擊破比特幣只差工程突破，170萬顆 BTC 處於高風險區

對比特幣而言，量子電腦的威脅已不再是科幻小說裡的假設。今年秋天，Castle Island Ventures 聯合創辦人 Nic Carter 推出一系列新文章及公開評論，明確指出比特幣面臨的最大長期威脅來源是量子運算。他強調，這其實是個工程難題，並非需要顛覆既有物理學的問題。這樣的立場正與量子理論專家 Scott Aaronson 的觀點互相呼應：打造能大規模執行 Shor 演算法的機器是「極端困難的工程挑戰」，但並不涉及推翻現行物理理論。

Carter 的第一篇文章深入介紹比特幣加密技術的原理及其暴露風險，是了解此議題的理想起點，而 Aaronson 則說明為何這純粹是工程問題而非理論問題。欲進一步瞭解詳情，請參考：Bitcoin and the Quantum Problem – Part I 與 Scott Aaronson 對量子電腦挑戰的說明。

什麼是「僅是工程挑戰」——從 2025 年來看

• 硬體與演算法持續進步。2025 年 5 月，Craig Gidney 展示如何利用不到一百萬個雜訊量子位元，在一週內分解 RSA‑2048，加速幅度遠遠超越 2019 年約需兩千萬量子位元的預估。即使 RSA 和 ECC（橢圓曲線密碼）屬於不同加密體系，這些突破的方向顯而易見：構築可破解密碼學的量子電腦（CRQC）所需資源正在迅速縮小。參見 Gidney 2025 年研究與 2019 年的初步里程碑：arXiv:2505.15917、arXiv:1905.09749
• 對量子攻擊者來說，破解 ECC 可能比破解 RSA 更「容易」。Roetteler、Naehrig、Svore 與 Lauter 的研究指出，針對橢圓曲線的離散對數問題，在相同安全等級下，所需量子資源會比分解質因數來得更少，這也是比特幣需要提前應對的重要理由之一。詳見：Quantum resource estimates for ECC discrete logs
• 問題不在物理，而在擴展能力。Aaronson 強調，現有物理理論足以支持量子電腦之建構，我們需要的只是大量可容錯的量子位元，加上材料控制與錯誤修正技術上的工程突破。簡明說明參見：YC 訪談摘要

到底有多少比特幣暴露於量子風險下？

人權基金會（Human Rights Foundation）在 2025 年的研究指出，約有 651 萬顆 BTC 暴露在可被長距離量子攻擊利用的情境中，這些風險大多來自公開密鑰已經洩露的錢包地址，例如歷史上使用的 P2PK（pay-to-public-key）、重複使用的地址，以及某些類型的 Taproot 支付地址。當中有約 172 萬顆 BTC 被認為處於休眠狀態且實際上難以移動（例如早期由 Satoshi 管理的地址），這正是媒體常提到的「處於危險線上的 1.7M BTC」。其餘約 449 萬顆 BTC，活躍使用者仍有機會在「Q 日」之前將其轉移到更安全的地址類型中。請參見完整報告：The Quantum Threat to Bitcoin

Deloitte 的另一本技術報告給出了類似結論，大約四分之一的比特幣供應坐落於已暴露的金鑰或重複使用的地址類型中，進一步強調了避免地址重用，以及小心處理舊有地址的重要性：Deloitte 對比特幣區塊鏈與量子威脅的研究

兩種量子攻擊模型：長距離 vs. 短距離

• 長距離攻擊針對的是公開在鏈上的密鑰（如 P2PK、重複使用的 P2PKH 地址、或特定類型的 Script）或以其他方式公開的密鑰（如洩漏的 xpubs）。一旦 CRQC 問世，這些將是最容易被攻擊的「成熟果實」。參考分類詳見 HRF 報告：Long‑range vs. short‑range
• 短距離（mempool）攻擊則針對交易在進入區塊之前、傳播中的那段時間。由於支出時會暴露公開金鑰，這種攻擊需要極高速、且具容錯能力的量子電腦才能實現，揭示「不重用地址」在後量子時代已不足以自保。關於地址格式與風險視窗的簡介，請參見 Project 11 的說明：Quantum vulnerability of Bitcoin addresses 與 ForkLog 的產業解析：ForkLog on Q‑day contingency

比特幣能透過軟分叉遷移到後量子簽章嗎？

原則上可以。BIP‑360（“Pay to Quantum‑Resistant Hash”，簡稱 P2QRH）是一項主要提案，允許透過新增指令碼操作碼或葉節點版本，於 tapscript 中驗證後量子簽章，意味著可透過軟分叉納入 NIST 已標準化的 PQC（後量子密碼）。亦即，不需重寫整個腳本系統，就能實現抗量子支出與遷移功能。技術細節與規格請參考：BIP‑360 官網 與 Delving Bitcoin 討論串

標準方面，美國國家標準與技術研究院（NIST）於 2024 年 8 月最終核定首批 PQC 加密套件：Kyber（ML‑KEM）用於金鑰交換，Dilithium（ML‑DSA）與 SPHINCS+（SLH‑DSA）用於簽章，為協議設計者提供了穩定的目標實作範本。參見：NIST PQC 標準公告、FIPS 204 (ML‑DSA)、FIPS 203 (ML‑KEM)

當然，權衡仍不可忽視。後量子簽章檔案大小顯著高於現有 ECDSA/Schnorr，導致交易手續費與區塊空間成本上升；而在錢包使用者體驗上，也需解決密鑰管理、分層金鑰推導（HD）與多重簽章設計等問題。目前社群正持續研究如何套用 PQC 於 HD 錢包、隱密地址（Stealth Address）與金鑰聚合等應用：Post‑quantum HD wallets & aggregation ideas

為何現在媒體大幅關注？

Nic Carter 多次疾呼比特幣開發者與機構應將量子危機視為長期嚴肅的工程專案看待，而非散播恐慌。他於 2025 年 10 月至 11 月期間發布的系列文章，完整揭示了現有風險、量子破解可能場景、以及建議的遷移優先順序。請參見：Part I、Part II: The Quantum Supremacy

如欲掌握當前（2025年12月18–20日）的討論現況，請參考 Carter 與開發者及研究人員之間的交流報導：ForkLog：「專家評估量子計算對比特幣的影響」

2025 年給持有者與建設者的實用建議

在比特幣尚未導入 PQC 前，你可以降低，但無法完全消除量子風險：

• 請避免地址重用，並盡量不要使用會公開金鑰的 Script。優先選擇 SegWit 單簽或現代化多簽格式，這些格式在未實際支出前不會曝光金鑰。若可行，盡量從 P2PK 與重複使用之 P2PKH 遷移。相關指引參查：Deloitte 概覽、Project 11 的地址暴露參考
• 瞭解 mempool 中的風險：即使是「安全類型」的地址，在支出時也會暴露金鑰。到了 CRQC 時代，確認速度差異將至關重要。詳見：ForkLog 關於長短期攻擊的說明
• 密切關注 BIP‑360 與相關提案。早期測試、混合運行模式（EC‑Schnorr + PQC）、以及錢包與工具的支援，將是確保平順遷移的關鍵。資源： BIP‑360 規格、Delving Bitcoin 討論串
• 跟上 NIST 的 PQC 標準與時程，讓你的機構能提前更新硬體簽章模組（HSM）、簽章服務與合規流程。參見：NIST PQC 標準公告

關於時間表與資源的一點說明

目前尚無任何可信來源聲稱已有能破解比特幣的量子電腦問世。但隨著資源需求的壓縮（如 Gidney 2025 年對 RSA 的突破）與容錯率的穩定進展，Carter 的主張變得越來越有說服力。ECC 仍是 Shor 演算法的主要攻擊目標，而完整的轉移流程——從設計、實作到涵蓋節點、錢包、託管與交易所——往往需耗時數年。背景補充請參見：Roetteler 等人關於 ECC 與 RSA 的分析 (2017)，與比特幣可望透過軟分叉採用的最新 PQC 標準：FIPS 204 / ML‑DSA

關於自託管者的提醒

自託管並不能「自動」防禦量子攻擊，但確實能讓你更快速地因應威脅：

• 你能自主決定何時、如何將幣從高風險地址轉移
• 你可隨時改善錢包使用衛生習慣：不重用地址、將 UTXO 分區管理、減少交易滯留 mempool 的時間
• 你能提早準備操作流程，例如備份、HD 推導路徑、試驗性交易，以為日後 PQC 升級鋪路

若你使用 OneKey 自託管錢包，目前已能離線簽署交易，並輕鬆生成新收款地址，這兩項習慣不僅能縮小暴露視窗，也能降低地址重用的風險。等到 PQC 標準趨於穩定，且比特幣啟用後量子軟分叉時，像 OneKey 這類支援固件升級的硬體錢包，即可提供用戶遷移指引、地址輪替支援與圖形操作介面，是協助你走過多年轉移旅程的不二利器，比在 Q 日時慌張應對好得多。

---

延伸閱讀參考

• Nic Carter 量子系列文章：第一部分、第二部分
• HRF 對暴露供應量的分析（6.51M BTC，其中約 1.72M 休眠）：The Quantum Threat to Bitcoin
• NIST 發布之 PQC 標準：官方公告、FIPS 204 (ML‑DSA)
• 比特幣導入 PQC 的軟分叉路徑：BIP‑360 規格、討論串
• 量子工程進展：《Gidney 2025》（破解 RSA‑2048 僅用 < 100 萬 qubits）](https://arxiv.org/abs/2505.15917)；ECC 預估基本背景：Roetteler 等人，2017
• 地址類型暴露與 Mempool 風險評估：Project 11 說明、ForkLog 概述