Bitcoin Core 更新前怎麼查？Windows 架構、磁碟格式與下載驗證（2026）

Bitcoin Core 更新前，先確認正在跑哪個版本，再查 Windows 位元數和區塊檔實際放在哪個磁碟。2026 年 10 月 28 日的三份安全公告雖然列出同一組修補版，undo 檔案問題卻仍保留 32 位元系統與 FAT32 的限制。下載了新版、檔案驗證相符，也還不能替這些環境條件打勾。

這篇適合已經運行節點、準備更新的使用者。請準備本機節點的查詢權限、Windows PowerShell、GnuPG，以及能對應目前啟動程式的部署紀錄；驗簽還需要所選建置者的可信完整指紋紀錄。後兩項可先向原本維護節點的人索取，核對要求見下文；缺項就標為待確認。成果是一份「運行版本—系統—區塊磁碟—下載驗證」紀錄；操作停在安裝前。若節點也管理錢包，先確認原有備份可取得，查核時不要匯出私鑰或提交錢包檔。

先向正在執行的節點查版本

在 Bitcoin Core 的節點診斷視窗找 Console（主控台）。以 32.1 英文介面為例，可由 Window → Console 開啟；Information（資訊）分頁也列有 Client version。舊版若選單不同，先找同名分頁，別把 PowerShell 當成 Core 主控台。這些欄位與入口可對照官方介面定義。在 Core 主控台只輸入下面這一行：

getnetworkinfo

保存回應中的 version 與 subversion。官方 RPC 文件把前者定義為伺服器版本，後者是伺服器的版本字串。接下來用 subversion 中的發行版號對照公告，並保留 version 原值供核對；protocolversion 是網路協定版本，不是 31.2、32.1 這類發行版。若是自訂建置，字串無法清楚對應發行版，就先向維護者確認，填「版本待確認」。

若原本就透過 bitcoin-cli 管理節點，沿用原有的連線、資料目錄與網路參數，查詢 getnetworkinfo 即可。要確認的是你準備更新的那一個節點；本機有多個節點或連到遠端時，先核對目標。無法連線就記「運行版本未確認」，不要拿下載檔名或 bitcoin-cli 自己的版本當替代答案。

四個修補版相同，漏洞範圍仍要分開看

三份公告都在 2026 年 10 月 28 日公開，列出的修補版本是 29.5、30.4、31.2、32.1。先按 subversion 的主要版本找分支，再比小版本。例如，假設回應顯示的發行版是 31.2，就對上公告的 31.x 修補點；只記「31.x」還不足以判定。這個示意只判讀本次修補版本，平台與磁碟條件仍要依下面三項分開查：

• CVE-2026-117350：非 Linux 的 TCP 記憶體耗盡。惡意對等節點可藉 TCP urgent data 讓接收資料持續堆積；公告明確排除 Linux，Windows、macOS、BSD 節點則在其描述的影響範圍內。
• CVE-2026-117349：暫停傳送的舊協定對等節點。對方假裝不支援 BIP31 的 ping 機制，並拖延讀取訊息，可能讓待傳佇列緩慢增加。這份公告不能套用上一項的「Linux 不受影響」結論。
• CVE-2026-117346：undo 檔案溢位。undo 資料供鏈重組時撤回區塊使用。公告把攻擊描述為實務上難以利用，並列為低嚴重性；但也明說這批版本在 32 位元系統，以及 blocks 目錄位於 FAT32 的節點，仍有殘留限制。

Linux 使用者可以排除第一項，仍要檢查另外兩項。Windows 使用者也不要把「非 Linux」和「32 位元」混在一起：前者是作業系統類別，後者是檔案定位能力相關的環境條件，64 位元 Windows 也要先更新。

另外，32.1 發行說明已把 29.x 與更舊版本列為生命週期結束，不再提供後續更新。因此 29.5 可以作為這次漏洞的修補紀錄，不能當成長期留在 29.x 的維護承諾。以下以官網目前提供的 32.1 Windows 套件示範驗檔；跨主要版本前，仍須讀目標版的升級與相容性說明。

Windows 架構與實際 blocks 磁碟，分兩次查

先在 Windows PowerShell 執行以下查詢；這段不要貼進 Core 主控台。Get-ComputerInfo可列出系統與作業系統屬性，請保存輸出的原始值：

Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsVersion,OsArchitecture,CsSystemType | Format-List

OsArchitecture 是作業系統架構，CsSystemType 則補充機器系統類型。64 位元作業系統這一項，不能單獨證明正在跑的 Core 執行檔也是 64 位元。本篇以可取得既有部署紀錄為前提：紀錄至少要有節點識別、目前啟動的執行檔完整路徑、當時套件的版本與完整檔名、下載來源及建置架構。把原本啟動設定中的路徑、第一步的節點回應與該紀錄互相核對；剛下載的新套件資料不能代填舊程式的架構。資料缺漏或對不上，就向維護者補查。

這次 Windows 下載示範選的是 win64 套件；若目前程式是自行建置、32 位元程式，或使用 ARM 機器、來源不明，先記「程式架構待確認」，停在盤點，不直接套用本例。32.1 官方列出的 Windows 支援測試基準為 Windows 10 1903 或更新版本。

接著回 Core 的 Information 分頁，抄下 Datadir 與 Blocksdir。查 FAT32 要看後者：程式裝在 C 槽，不代表區塊也在 C 槽。官方路徑處理原始碼會依 -blocksdir、網路與 blocks 子目錄組合實際位置；不要只照設定檔中的父目錄猜。

以下假設你剛抄到的完整 Blocksdir 是 D:\BitcoinData\blocks。先把第一行改成自己的實際路徑，再執行；這段找一個已存在的區塊檔，交給 Get-Volume -FilePath查所屬磁碟區：

$blocksPath = 'D:\BitcoinData\blocks'
$blockFile = Get-ChildItem -LiteralPath $blocksPath -Filter 'blk*.dat' -File | Select-Object -First 1
if ($null -eq $blockFile) { throw '找不到區塊檔，先確認 Blocksdir' }
Get-Volume -FilePath $blockFile.FullName | Format-List DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size

預期會得到磁碟區與 FileSystem，把結果和完整區塊檔路徑一起存下來。若顯示 FAT32，這項就填「更新仍未解除」；若是 NTFS 等其他格式，就記「未命中 FAT32 條件」，再核對其他項目。公告保留的 32 位元檔案定位上限是 2 GiB，FAT32 單檔限制則是 4 GiB，兩者也不能用磁碟總剩餘空間代替。

找不到指令、查詢失敗或沒有區塊檔時，先核對 PowerShell 環境、存取權限與 Blocksdir。若資料經接合點、網路分享或特殊儲存配置轉向其他位置，先請管理者確認實際檔案系統；查不清就填「磁碟條件未確認」。這裡不要格式化磁碟、搬移資料或刪除 rev*.dat 來嘗試消除警告。

同一版本取三份檔案，再比對雜湊

自行輸入 Bitcoin Core 官方下載頁，確認目標版本與平台，再從它連出的32.1 發行目錄取得 bitcoin-32.1-win64-setup.exe、SHA256SUMS 及 SHA256SUMS.asc。另建一個空資料夾存這三份檔案；如果你選的是 31.2，就三份都回到 31.2 目錄取得，不拿 32.1 的清單混用。

本例是 Windows 安裝程式。目錄裡另有 ZIP、debug、unsigned 與 codesigning 檔案；名稱不同就分開核對，不把看起來相近的檔案當成同一個。下載失敗、只存到錯誤網頁，或瀏覽器另加編號時，先回官方入口確認實際檔名與位置。不要在檔案還沒驗完前啟動安裝程式。

在 PowerShell 以 Set-Location -LiteralPath '你的下載資料夾完整路徑' 進入剛才的資料夾；把引號內文字換成實際路徑。先用 Get-Location 確認位置，再執行：

Get-FileHash -LiteralPath '.\bitcoin-32.1-win64-setup.exe' -Algorithm SHA256 | Format-List
Get-Content -LiteralPath '.\SHA256SUMS'

Get-FileHash會列出演算法、雜湊與實際檔案路徑。在清單中找完整檔名恰好相同的那一行，逐字核對雜湊的全部十六進位值；不要只找任意一個相同的開頭。找不到該檔名、值不同或路徑不對就停止，另建空資料夾重新取得同版本三份檔案。

雜湊相符後，還要確認誰簽了清單

雜湊讓套件對上清單，簽章再把清單對上簽署公鑰。如果清單本身來源不可信，只比雜湊還不夠。官方下載頁要求挑選數位你信任的建置者，以其公鑰驗證 SHA256SUMS。公鑰可從下載頁連結的 guix.sigs 專案之 builder-keys 取得；其目錄說明也區分正式發行套件與建置階段的雜湊，不要混拿 noncodesigned.SHA256SUMS。

先執行 gpg --version 確認工具可用；找不到時，從 Core 下載頁提供的 GnuPG 安裝入口準備工具。以下以官網舉例的 fanquake.gpg 為一把公鑰示範：從該專案的 builder-keys/fanquake.gpg 下載到同一資料夾，先查看完整主金鑰指紋。

gpg --show-keys --with-fingerprint .\fanquake.gpg

把完整主金鑰指紋與開頭準備的可信紀錄交叉核對，再匯入。這份紀錄應能交代簽署者、完整指紋，以及先前如何確認持有人身分；向維護者索取時，也要問清楚其確認途徑。若只是這次從同一專案一起下載的公鑰與姓名，仍共用同一個信任起點。本文沒有提供已獨立確認的建置者指紋。手邊尚無可信紀錄時，本篇能完成的是檔案雜湊與「簽章是否符合這把公鑰」的核對；身分欄填「未確認」，停在驗證紀錄，不進入安裝。

gpg --import .\fanquake.gpg
gpg --status-fd 1 --verify .\SHA256SUMS.asc .\SHA256SUMS 1> gpg-status.txt 2> gpg-output.txt
$gpgCode = $LASTEXITCODE
Set-Content -LiteralPath gpg-exit.txt -Value $gpgCode
Get-Content -LiteralPath gpg-output.txt
Get-Content -LiteralPath gpg-status.txt
Get-Content -LiteralPath gpg-exit.txt

GnuPG 手冊建議把分離式簽章與被簽資料兩個檔名都寫明。這裡驗的是清單，並非拿 SHA256SUMS.asc 直接驗安裝程式。對其他已確認可信的簽署者，逐一取得及核對公鑰後再驗；不要把只匯入範例這一把鑰匙視為已完成官網建議的多位可信簽署者核對。

• Good signature 與 VALIDSIG：按下面的欄位示意，逐筆比對完整主金鑰指紋是否與預期一致，按簽署者各填一列。
• No public key：那一筆是缺鑰、未驗證，不等於另一位簽署者的有效簽章也失效。若缺的是你原本選定信任的人，回官方公鑰入口補齊並重驗。
• 未認證的金鑰警告：依前面的可信指紋紀錄確認身分，與密碼學驗證結果分欄保存；警告本身不等同於壞簽章。
• BAD signature、指紋不符、撤銷、過期或其他未釐清錯誤：停止安裝，保存完整訊息與結束碼，回查配對檔案、公鑰與版本。任何非零結束碼都先逐筆找原因。

以下依GnuPG 狀態規格列出格式示意，不是本次實測輸出；大括號內都是欄位名稱。一個 NEWSIG 開始一筆，到下一個 NEWSIG 前為止；最後一筆讀到檔案末尾。同一筆內還可能有其他狀態行，要一併保留判讀。

[GNUPG:] NEWSIG
[GNUPG:] GOODSIG {金鑰識別值} {顯示名稱}
[GNUPG:] VALIDSIG {簽署金鑰指紋} {日期} {建立時間} {到期時間} {簽章版本} {保留值} {公鑰演算法} {雜湊演算法} {簽章類別} {主金鑰指紋：可選}
[GNUPG:] NEWSIG
{下一筆的狀態行}

VALIDSIG 後第 1 個值是實際簽署金鑰的完整指紋；第 10 個值若有出現，位於簽章類別之後，才是主金鑰指紋，可能與第 1 個相同。用主金鑰指紋對照先前的可信紀錄；若主金鑰欄位未出現，先保存簽署指紋，再請維護者協助核對該公鑰的主／子鑰對應。對應未釐清就填「主金鑰待確認」，保持停止安裝，不把第 1 個值直接當成主金鑰。

保存核對表，符合條件才進入更新

把以下欄位複製到自己的紀錄，每個待確認項目都留白或寫原因，別預填「通過」。這份紀錄的用途，是讓下一步能分辨要換套件、查儲存環境，還是補公鑰身分證據。

查核日期與節點識別：
運行中的 version／subversion：
目標版本及公告修補點：
Windows 版本／OsArchitecture／CsSystemType：
目前啟動的 Core 執行檔路徑／套件來源與架構：
Datadir／實際 Blocksdir：
實際區塊檔路徑／磁碟區／FileSystem：
32 位元或 FAT32 殘留條件：
官方下載入口／三份檔案的完整 URL 與檔名：
套件 SHA256／清單同名列／是否完全一致：
各簽署者／完整主金鑰指紋／可信指紋來源：
逐筆簽章結果／身分確認結果／整體結束碼：
待確認事項與下一步：

如果運行版本、程式架構或實際磁碟尚未確認，先完成盤點；如果雜湊或可信簽章不符，先處理下載與驗證；如果仍是 32 位元系統或 FAT32，就把環境處理列為獨立工作，不能只靠這批更新結案。公告也說，undo 資料若已遭破壞，重啟本身無法恢復，需以修補版進行 -reindex；不要看到節點啟動失敗，就未經診斷套用這個重建選項。

本篇到這份安裝前紀錄完成為止。所有適用條件與可信驗證都確認後，下一階段才是依目標版本發行說明完成更新；本篇沒有涵蓋完整安裝程序。官方順序是先正常關閉舊節點、等完全結束，再執行已驗證的 Windows 安裝程式。屆時更新完成，還要向同一節點再查一次 getnetworkinfo，把新回應補進紀錄，確認實際運行的程式已換版。