發生什麼：新增「容易發現」漏洞類別
Bitcoin Core 官網的安全政策頁在 2026 年 10 月 22 日更新。依 GitHub 紀錄，這項修訂是 bitcoin-core/bitcoincore.org 的 PR #1281，由 GitHub 帳號 darosior 於 10 月 16 日開啟，10 月 22 日 16:06（UTC）合併；同日 18:07（UTC），Antoine Poinsot 在 bitcoindev 開發者郵件列表發信說明。
新版政策寫明，漏洞的公開時程將取決於回報後是否被歸類為「容易發現」（easily discoverable），也就是能以極少功夫找到的漏洞，政策舉的例子是「透過簡單的 LLM 提示」。對這一類漏洞，團隊會為每個維護中的主要版本盡快發布含修補的小版本，並同時發布安全公告，不套用原本依嚴重度而定的封鎖期；其他漏洞仍照舊時程處理。
PR 內容同時把「公開細節前兩週先預告」的規定限縮為只適用於「受封鎖的漏洞」，因為容易發現的漏洞不再先封鎖。
原本怎麼做：修補常等下一個主要版本，細節最長約一年後才公開
依政策頁，Bitcoin Core 把漏洞分為 Critical、High、Medium、Low 四級。Low 級在含修補的主要版本釋出 2 週後揭露；Medium 與 High 級則在最後一個受影響版本進入生命週期終點（EOL）後 2 週揭露，政策頁自己估算約為含修補主要版本首次釋出後一年。Critical 級不在標準流程內，政策說這類問題很可能需要個案處理。
Poinsot 在郵件中解釋，由於專案性質加上使用者升級慢，原政策偏向較長的封鎖期，代價是安全修補通常無法回補到舊版，只能隨下一個主要版本提供給使用者。Lifecycle 頁則說明，專案維護最新三個主要版本；以 32.0 正式版截至 10 月 23 日上午（台北時間）尚未在官網下載目錄出現計，目前維護中的應是 29.x、30.x 與 31.x，這是本站依該規則推算。
為什麼改：LLM 讓「暗中修補」藏不住
Poinsot 表示，近期可被輕易發現或重新發現的漏洞回報數量增加，主要原因是 LLM 大幅降低找出特定類型問題、或辨識「暗中修補」（covert fixes）的門檻。他寫道，任何安全政策都在透明度與給使用者足夠升級時間之間取捨；對容易被找到的問題來說，封鎖期「作用不大，卻延後修補版本的釋出」，因此是錯誤的取捨。
郵件和 PR 都沒有公開回報增加的具體數量、時間範圍或涉及哪些漏洞，也沒有說明「容易發現」的量化門檻。Poinsot 只表示實務上預期是「用簡單提示就能讓 LLM 找到的問題」，但分類並不限於此，由團隊在分類（triage）階段判斷。
對節點營運者與服務商的影響
最直接的變化是：仍跑舊主要版本的節點，未來可能比過去更常收到針對自己版本的安全小版本，而不是只能等升級到下一個主要版本才拿到修補。對交易所、支付處理商、礦池與錢包後端這類依賴 Bitcoin Core 節點的服務來說，這也代表安全公告可能與修補版本同步出現，攻擊者與防守方幾乎同時得知細節，升級窗口會比以往的封鎖模式短。
仍維持不變的部分：非「容易發現」的漏洞照舊依嚴重度封鎖；已進入 EOL 的版本不在維護範圍，政策只承諾回補「維護中」的主要版本。
AI 觀點分析與推論
AI 觀點：封鎖期的前提已經變了，真正的壓力轉到營運端
我傾向認為這是合理而且遲早要做的調整。長封鎖期的前提是「修補可以低調地混在大版本裡，攻擊者不容易從程式碼差異反推漏洞」。若 LLM 能讀 commit 就指出哪一段是安全修補，這個前提就不成立：封鎖期不再保護使用者，只是讓舊版用戶在別人可能已經知道的情況下繼續暴露。
受益者是跑舊主要版本、不願頻繁大升級的營運者；壓力則落在需要更快測試與部署小版本的服務商，以及維護者自己，因為同時回補三個主要版本的工作量不小。反面情境是：如果「容易發現」的判斷過寬，等於把更多細節更早公開，給未及時升級的節點帶來風險；判斷過嚴，則改革形同虛設。
我會看兩個後續訊號來修正判斷：一是未來的安全公告是否明確標示「依容易發現類別處理」以及從回報到發版花了多久；二是這類小版本出現後，公開節點的版本分布多快跟上。如果營運端升級速度沒有改善，政策再快，實際保護效果仍有限。
限制與下一步可觀察事項
這次修改的是揭露與發版流程，不涉及比特幣共識規則，也不代表目前已有特定公開漏洞。實際效果要等第一批依新類別處理的公告出現後才能評估。
- 政策未公開回報增加的數量或具體漏洞，本文不推測。
- 「容易發現」由團隊個案判斷，沒有量化標準。
- Critical 級漏洞仍不在標準流程，另以特別程序處理。
- 可觀察：首份依新類別發布的安全公告與對應小版本；32.0 正式版發布後，維護中版本將改為最新三個主要版本。
