比特币核心项目（Bitcoin Core）本周四合并了一项安全政策修订：对于大语言模型（LLM）能轻易重新发现的漏洞，不再执行长达数月的保密期，而是立即向所有仍在维护的主版本回移修复、尽快发布点版本，并同步公开安全公告。
这项提案由 Chaincode Labs 开发者 Antoine Poinsot 撰写，他在同一天向比特币开发邮件列表宣布了该消息。Poinsot 写道："我们最近经历了可被轻易（重新）发现的安全漏洞报告数量增加，这很大程度上是因为 LLM 大幅降低了发现某些类别问题或识别隐蔽修复的门槛。"
旧规则：按严重程度分级保密
比特币核心软件运行在比特币网络大多数节点上，此前对每个上报漏洞按严重程度分级并安排披露时间。低严重性漏洞在下一个主版本发布两周后公开；中、高严重性漏洞则一直保密到最后一个受影响版本停止维护（EOL）后两周，这一跨度可能长达一年。
这套时间表原本是为了给升级缓慢的节点运营者留出迁移到已修复软件的时间。但在实践中，这意味着旧维护版本上的修复迟迟不发布，要等到下一个主版本才随附。Poinsot 认为，对于容易被重新发现的漏洞，这种权衡已经失效。政策文本写道："保密期几乎起不到作用，却延迟了修复版本的可用性。"
新规则：标记"易发现"即快速通道
在漏洞分诊阶段，比特币核心可以将某个漏洞标记为"易发现"，政策定义为"以极小努力即可发现，例如通过简单的 LLM 提示词"就能找到的问题。该标签也适用于通过其他方式发现的漏洞。
对于这类问题，项目将把修复回移到每一个仍在维护的主版本，尽快发布点版本，并在修复软件发布的同时公开包含部分细节的安全公告。Poinsot 承认，这类修复在到达用户前测试时间会更短。
不在该类别中的漏洞仍按现有严重程度时间表处理。关键漏洞------那些可能在协议层面导致盗币、增发供应或造成永久链分裂的问题------仍不适用标准政策，将逐案处理。
开发者 Antoine Riard 曾主张增加一个选项：在某些情况下只发布修复而不发公告、不披露细节。Poinsot 拒绝了这一提议，他写道，只提醒用户而不提供细节"可能不必要地制造更多风险"，促使原本不受影响的用户仓促迁移。
AI 报告潮的压力
这一政策调整的背景是比特币开源项目近几个月承受的压力。7 月下旬，一个由 16 名开发者组成的志愿者团体"比特币红队"（Bitcoin Red Team）在大约一天内对 390 个比特币代码仓库运行 AI 模型，记录了 4,962 条发现，其中 85 条被评为关键级别。
几天之内，该团体私下报告的 BTCPay Server 漏洞就在活跃的商户服务器上被利用，导致闪电节点资金被耗尽。8 月，Core Lightning 开发者建议运营者升级或断开连接，原因是 AI 生成的报告被证明准确。