Core Lightning 26.06.9修复支付节点安全问题和流量延迟
来源发布日期: 2026-10-07 · 编辑分析发布日期: 2026-10-09
10 月 7 日的版本修复了 26.06.8 gossip 回归，加强了通道和 API 保护，并添加了签名的 ARM 版本。 维护人员建议立即升级。
分析与实际影响
本节为本站分析及示例计算，与来源报道分开呈现。
支付层已发布更新
Core Lightning 于 2026 年 10 月 7 日在 GitHub 上发布了版本 26.06.9。其标记的变更日志日期为 10 月 6 日。维护者建议立即安装此版本； 它包括安全修复并修复了 26.06.8 中引入的消息处理回归。 这是支付节点软件，而不是 ASIC 固件或比特币共识变更。 这种区别对于同时运行闪电服务和算力的挖矿企业来说很重要：更新支付服务器不会改变矿机的算力、功率设置或区块奖励。
ASIC.tools 直接检查版本和版本变更日志。 下面的实际分析涉及运营节点及其周边服务，而不是承诺增加挖矿收入。 仅接收普通链上支出的矿场可能没有需要更新的Core Lightning部署。 接受闪电网络支付托管、热量或服务的公司应该首先确定实际的实施和版本，因为类似名称的比特币产品有单独的发布时间表和迁移程序。
为什么繁忙的节点会延迟消息
该版本描述了对gossip CPU 预算的修正：普通gossip流量、ping 和洋葱消息不再消耗用于gossip查询的配额。 在 26.06.8 中，繁忙的节点可能会限制对等节点并延迟通道流量。 因此，记录的回归涉及该版本中的工作负载处理，而不是所有闪电支付都被破坏或比特币区块停止到达的证据。 该更新针对特定的会计错误，同时保留其要控制的查询的预算。
对于运营商来说，一个有用的区别是应用程序超时和支付失败。 如果结帐等待的时间比预期长，盲目重试可能会造成发票、未完成的尝试和会计记录的混乱序列。 在将超时视为新销售之前，更好的操作检查将付款标识符、发票状态和最终结算联系起来。 升级后，比较相同的工作负载和观察间隔：仅偶尔的快速响应并不能证明现在最繁忙的时段得到了正确处理。
通道关闭和付款期限
带版本标签的变更日志修复了在通道关闭过程中达到期限的已提出HTLC处理：节点现在会强制关闭该通道，以防止延迟履行导致转发资金损失。HTLC是条件支付合约，而不是提交给矿池的ASIC share。修复涉及链下通道运行与链上执行之间的边界，不保证收回已经损失的资金，也不意味着每个已关闭通道都曾有漏洞。
运营商的会计必须反映这两个层面。 通道流动性与已确认的可支出链上余额不同，通道关闭交易可能会产生交易费用和等待期。 对于挖矿托管服务来说，这种区别会影响电力和客户退款的可用工作余额。 明智的运营响应是将通道状态和结算记录与应用程序的分类账进行核对，而不是从单个仪表板数字或成功的测试付款来推断偿付能力。
API 权限值得单独审查
该版本加强了基于符文的 API 授权，并屏蔽了多个敏感配置值。 变更日志还关闭了持久配置注入路径，并根据相关限制检查方法别名。 这些是服务器管理更改； 在这种情况下，符文是授权凭证，而不是加密货币令牌。 操作员应根据自己的集成读取命名方法更改，尤其是在监控或计费服务使用故意限制的凭据的情况下。
独立于该特定补丁，计费服务通常不需要与人工管理员相同的权限。 将只读监控与支付执行和配置更改分开可以使集成更容易审核。 升级是一个机会来检查哪个进程持有每个凭证、凭证的存储位置以及如何撤销。 一个健康的监控屏幕应该证明所需的呼叫仍然可以在预期的限制下工作； 它不应该依赖于悄悄地用不受限制的访问取代受限制的凭证。
已签名的二进制文件可用于更多架构
该版本除了 amd64 之外，还为 Ubuntu 22.04、24.04 和 26.04 添加了可复现构建的 arm64 和 armv7 二进制文件。 每个架构都有自己的签名校验和清单。 已发布的验证过程检查清单签名，然后检查文件校验和。 特定于体系结构的文件很重要：ARM 设备和 x86 服务器不能简单地交换二进制文件，因为两者都运行 Linux。 运营商还需要与其分发和部署方法相匹配的软件包，而不是只选择看起来最新的下载。
校验和回答下载的字节是否与清单匹配； 经过验证的签名将该清单与您选择信任的签名密钥连接起来。 两项检查都有其目的。 保存准确的工件名称、版本和验证结果使得以后的故障排除比编写“更新到最新”更加精确。 当多台计算机在不同时间安装时，或者当容器映像和主机包具有单独的更新机制并且实际上可能包含不同版本时，这特别有用。
数据库兼容性限制回滚
维护者警告说，由于较新的数据库架构，已运行开发分支master的构建的节点无法降级到 26.06.x 版本。 他们还对实验性双重融资和与不受信任的同行的零确认通道保持谨慎。 这并不意味着公开的维护版本本身是开发快照。 这意味着升级路径取决于节点的历史记录，因此仅工作二进制文件无法确定打开现有数据目录是否兼容。
作为操作原则，在更改软件之前记录起始版本、软件包来源、启用的插件和存储布局。 备份必须遵循应用程序自身的一致性和恢复指南； 复制任意实时数据库文件不会自动成为有效的恢复计划。 同样，恢复旧的通道状态并不等同于恢复静态网站。 将回滚操作系统的能力与回滚支付状态的能力分开对待，并在合适的非生产设置上测试维护程序。
维护后有用的验收检查
我们建议的验收检查重点关注节点实际提供的服务。 确认它到达其比特币后端，重新连接到预期的对等点并仅公开预期的管理接口。 然后通过客户使用的同一应用程序验证受控发票及其最终状态。 在代表性的繁忙时间间隔内观察错误日志、未付款项和对账结果。 这些是对您的部署的实际检查，而不是 Core Lightning 测量的性能数据或每个第三方插件都兼容的承诺。
对于矿场，将支付可用性和挖矿可用性作为不同的指标。 延迟的客户发票可能需要引起注意，同时 ASIC 队列继续正常散列； 相反，成功的付款不会告诉您有关冷却泵故障或share被拒绝的信息。 分别报告两者可以帮助员工诊断正确的系统，并避免将支付节点问题归咎于 ASIC 固件版本。 当维护窗口影响支付服务但仍保持其托管挖矿设备运行时，它还可以为客户提供更清晰的解释。
该公告规定了什么和没有规定什么
该更新已可用，但维护人员暂时未公开安全修复测试，以便操作员有时间安装修复程序。 该发布选择并不是未来版本未发布的证据，也不是等待漏洞利用演示的理由。 请遵循官方发行说明进行安装和兼容性决策。 该版本的描述性昵称本身并不能证明比特币挖矿或每笔闪电交易都获得了新的量子安全保证； 技术行为必须根据实施和文档来确定。
本文使用了计算和网络设备的不同许可档案照片。 它们说明了操作环境，但没有描述发布团队或受损的安装。 当变更日志和发布日期得到确认后，ASIC.tools 会将后续版本视为单独的事件。 对于此版本，立即做出的决定是具体的：确定您的服务是否运行 Core Lightning，查看记录的更改并选择具有经过验证的安装工件的兼容维护路径。
来源: Core Lightning ↗ · Versioned 26.06.9 changelog ↗
挖矿计算器 ↗
