全文
可用性也是支付安全的一部分
Bitcoin Optech 第 427 期同时涵盖 Eclair 通道开启漏洞与 LN-GAP 研究。依该期历史披露，相关 Eclair 修正已在 v0.14.1 发布；这是理解当时事件的信息，并非建议今天只安装该旧版本，现行部署仍需核对客户端的维护版本。
这类事件说明，支付系统除了防止未授权支出，也需要维持服务可用。若有限资源被未完成的工作占满，即使资金权限没有改变，使用者仍可能无法及时执行正常操作。资源管理因而是安全设计的一部分。
限制数量必须对应真实资源
假设系统允许最多十件待处理工作，但计数器依可重复的外部标签计算，而每件工作都另外占用记忆体。只要计数方式与实际配置资源的方式不同，画面显示的十件限制就未必限制住真正的负荷。这是抽象示例，不是攻击操作说明。
比较可靠的设计是以伺服器自己的工作身分管理生命周期，在成功、取消、逾时与重启后都核对资源回收。测试也应覆盖状态转换，而不只是检查单次请求格式正确。正常输入的组合有时会揭露单一输入测试看不到的问题。
多回合合约难在证明谁没有回应
LN-GAP 的研究则关注双方需要反覆互动的合约。能验证一则已公开讯息是否符合规则，与能证明某方在期限内没有交出讯息，是两个不同任务；后者需要先定义哪里算发布，以及谁能可靠观察时间。
假设双方轮流提交答案，每轮有固定截止点。若其中一方说已送出，另一方说没收到，只靠两人的陈述不能解决争议。研究中的见证安排处理的就是这类时间与发布问题，但见证者是否可靠仍是安全假设的一部分。
不保管资金不等于无法影响资金
一个角色即使没有直接持有私钥，也可能透过决定哪些证据有效而影响结算结果。阅读「非托管」描述时，应继续追问：谁能提供关键证明、错误证明会造成什么后果，以及使用者有哪些反驳窗口。
本文的编辑判断是，这期两个主题共同提醒我们检查状态管理。漏洞修补着重工作如何开始与结束；合约研究着重谁能证明互动曾发生。前者是已披露修正，后者是研究设计，两者的成熟度与使用方式必须分开理解。