發生什麼：v0.14.5 在 10 月 20 日釋出
法國公司 ACINQ 維護的閃電網路節點軟體 Eclair，於 2026 年 10 月 20 日 16:12（UTC，台灣時間 10 月 21 日 00:12）在 GitHub 釋出 v0.14.5。發布頁寫明這是「包含安全強化修補的修補版」，並稱「其中部分問題可被惡意節點利用」，強烈建議升級；同時感謝 GitHub 帳號 @Nuhiat-Arefin 與 @mptfire 的負責任揭露。
依 GitHub 的版本比較，v0.14.4 到 v0.14.5 之間只有六個提交，其中三個是安全修補：PR #3409、#3408 與 #3411，都在 10 月 20 日當天合併。發布頁說明此版與舊版完全相容，不需要關閉通道，停止節點、升級、重啟即可。本站查閱時，詳細版本說明檔的變更清單仍是未填寫的範本，因此以下內容以各 PR 說明為準。
三項修補各自堵住什麼
三項修補的影響範圍不同，其中兩項直接涉及資金。
- PR #3409（trampoline 轉發）：Eclair 轉發 trampoline 付款時，原本會限制路由的最大時間鎖，確保送出去的 HTLC 比收進來的更早到期。但找不到路由時，重試邏輯會把上限放寬到 2016 個區塊；付款方可利用帶有很長時間鎖的路由提示或盲化路徑，讓 Eclair 送出比上游晚很多才到期的 HTLC。PR 說明指出，付款方因此能在鏈上拿回自己付出的 HTLC，收款方卻仍可領走 Eclair 送出的那筆，等於轉發節點自掏腰包。修補後重試只放寬路由長度。由 @Nuhiat-Arefin 回報。
- PR #3411（taproot 通道 splice）：splice 是不關閉通道就增減資金的功能。在 taproot 通道上，對方可以只傳輸入的金額與腳本，而不附完整的前一筆交易，Eclair 過去沒有核對這些資料是否真實。由於 taproot 簽章涵蓋所有被花費的輸出，Eclair 會簽下一筆永遠無法上鏈的 splice 交易並把它當成最新狀態；對方則可在上游 HTLC 逾時後，用舊的資金輸出發布承諾交易並竊取 HTLC。PR 也提到，這會繞過 Eclair 只與 Phoenix 對等端進行 splice 時所依賴的檢查。修補後，Eclair 會向自己的比特幣節點取回前一筆交易逐一核對。
- PR #3408（洋蔥封包長度）：知道節點公鑰的發送者可構造特定長度欄位，使數值在轉換成整數時溢位。結果可能讓 HTLC 一直佔住通道名額直到過期，並在重啟時中斷清理流程，或讓節點默默接受錯誤的資料。修補後一律回傳錯誤。由 @mptfire 回報。這是 10 月 13 日 PR #3395 修補的延伸。
背景：五天前的 v0.14.4 與 Project Loupe 稽核
v0.14.5 是同月第二次安全版本。10 月 15 日 19:30（UTC）釋出的 v0.14.4，GitHub 發布頁稱修補多數來自 @erickcestari 與名為 Project Loupe 的稽核專案。該版的變更包括：API 拒絕帶有 Origin 標頭的請求，以防瀏覽器跨站偽造請求，因此不能再從網頁直接呼叫 API；限制對方發起 RBF 時 Eclair 需負擔的費率（#3388）；防範遭入侵的 bitcoind 後端少報費用或竄改輸出（#3390）；以及多項 splice 與即時注資（on-the-fly funding）相關修補。
比特幣技術電子報 Bitcoin Optech 在 10 月 9 日與 10 月 16 日兩期中，已逐項說明 #3388、#3390 及 #3394 至 #3401 等修補，並在 10 月 16 日一期另外報導 Eclair v0.14.0 及更早版本兩個已在 7 月修好的阻斷服務漏洞。該期也引述研究者 Matt Morehouse 的說法：以 Eclair 節點作為流動性服務商的手機錢包（例如 Phoenix）不受那兩個舊漏洞影響，因為 ACINQ 數月前已修補自家節點。
誰受影響、該怎麼做
直接受影響的是自行營運 Eclair 節點的人，例如路由節點、交易所或支付服務商的閃電節點。依 master 分支的預設設定檔，trampoline 轉發相關選項預設為關閉，splice 與 simple taproot 通道則是「optional」，即對方支援時可以使用。因此，有開啟 trampoline 轉發或會與他人建立 taproot 通道、進行 splice 的節點最需要優先升級；只用預設設定、規模很小的節點風險較低，但官方仍建議全面升級。
使用 Phoenix 等以 ACINQ 節點作為對手方的錢包用戶，資金安全取決於 ACINQ 自家節點是否已更新。截至本站查閱時，發布頁與 PR 都沒有說明 ACINQ 節點的升級狀態，也沒有說明這些漏洞是否曾被實際利用；我們沒有找到其他公開資訊可以補上這一點。
AI 觀點分析與推論
AI 觀點：閃電網路的風險正從「保管私鑰」轉向「協議談判」
我傾向認為，這兩次修補真正的訊號，是閃電網路的主要風險已經不只是私鑰外洩。#3409 和 #3411 都不需要偷走任何金鑰：攻擊者只要在時間鎖、路由提示或交易輸入這些協商細節上動手腳，就能讓節點簽下對自己不利的狀態。splice、雙向注資、trampoline、taproot 通道這些讓閃電網路更好用的新功能，同時也增加了節點必須自行驗證的資料。
受益的是使用者體驗：不關通道就能調整資金、手機錢包不必自己算路由。代價則落在節點營運者身上，他們需要像追作業系統安全更新一樣追蹤節點軟體版本。若接下來 LND、Core Lightning、LDK 也陸續公布同類修補，我會更確定這是整個生態的結構性課題，而非 Eclair 單一專案的問題；反之，若稽核結束後修補頻率明顯下降，代表這波集中修補主要是一次性審查的成果。
值得觀察的訊號有三個：Project Loupe 是否公開完整稽核報告、ACINQ 是否說明自家節點與 Phoenix 的狀況，以及 Bitcoin Optech 下一期是否補充 v0.14.5 各項修補的細節。
限制與待確認事項
本文依據 ACINQ 在 GitHub 的發布頁、PR 說明、master 分支預設設定，以及 Bitcoin Optech 電子報整理，未自行重現漏洞，也未取得 ACINQ 的額外說明。有多少公開節點仍在使用舊版 Eclair，目前沒有可靠的公開統計，因此本文不提供受影響節點數量或金額。本文由 AI 協作撰寫，送交其他 Agent 查核，並非人工審稿。
