全文
可用性也是支付安全的一部分
Bitcoin Optech 第 427 期同時涵蓋 Eclair 通道開啟漏洞與 LN-GAP 研究。依該期歷史披露，相關 Eclair 修正已在 v0.14.1 發布；這是理解當時事件的資訊，並非建議今天只安裝該舊版本，現行部署仍需核對客戶端的維護版本。
這類事件說明，支付系統除了防止未授權支出，也需要維持服務可用。若有限資源被未完成的工作占滿，即使資金權限沒有改變，使用者仍可能無法及時執行正常操作。資源管理因而是安全設計的一部分。
限制數量必須對應真實資源
假設系統允許最多十件待處理工作，但計數器依可重複的外部標籤計算，而每件工作都另外占用記憶體。只要計數方式與實際配置資源的方式不同，畫面顯示的十件限制就未必限制住真正的負荷。這是抽象示例，不是攻擊操作說明。
比較可靠的設計是以伺服器自己的工作身分管理生命週期，在成功、取消、逾時與重啟後都核對資源回收。測試也應覆蓋狀態轉換，而不只是檢查單次請求格式正確。正常輸入的組合有時會揭露單一輸入測試看不到的問題。
多回合合約難在證明誰沒有回應
LN-GAP 的研究則關注雙方需要反覆互動的合約。能驗證一則已公開訊息是否符合規則，與能證明某方在期限內沒有交出訊息，是兩個不同任務；後者需要先定義哪裡算發布，以及誰能可靠觀察時間。
假設雙方輪流提交答案，每輪有固定截止點。若其中一方說已送出，另一方說沒收到，只靠兩人的陳述不能解決爭議。研究中的見證安排處理的就是這類時間與發布問題，但見證者是否可靠仍是安全假設的一部分。
不保管資金不等於無法影響資金
一個角色即使沒有直接持有私鑰，也可能透過決定哪些證據有效而影響結算結果。閱讀「非託管」描述時，應繼續追問：誰能提供關鍵證明、錯誤證明會造成什麼後果，以及使用者有哪些反駁窗口。
本文的編輯判斷是，這期兩個主題共同提醒我們檢查狀態管理。漏洞修補著重工作如何開始與結束；合約研究著重誰能證明互動曾發生。前者是已披露修正，後者是研究設計，兩者的成熟度與使用方式必須分開理解。