10月28日，Bitcoin Core公开了三项安全漏洞：两项涉及内存无界增长，另一项涉及极端条件下的撤销文件位置溢出。官方为29.5、30.4、31.2和32.1提供对应修复，但第三项通报明确保留了32位系统和FAT32文件系统的限制。[1][2][3] 对自建钱包、区块浏览器和支付服务来说，这次事件的判断重点是节点能否持续工作，以及故障后能否恢复；只在后台记录一个“已经升级”的版本号，仍不足以完成验收。
同样是内存增长，两条出问题的通道不同
第一项漏洞出在发送队列。节点遇到读取缓慢的对端，会暂停向其发送消息，缓解积压；然而，部分公告仍会进入队列。正常情况下，对端在20分钟内不响应带随机数的ping，就会断开连接。冒充不支持BIP31的旧协议对端可以避开这项断开逻辑，让暂停状态持续，队列也随之增长。[1] 限流开关存在，但队列的入口和连接的寿命没有一起收紧，资源占用便可能继续累积。
官方给出的增长上限是每条入站连接每小时2MB、每条出站连接每小时5MB，并指出仅接收区块的节点受影响较小，因为积压内容主要是交易公告。[1] 这些数字有明确的连接单位与时间单位，不能当成所有节点每小时固定增加的内存。对运营者而言，关注连接持续时间、异常对端数量及内存余量，比只看某一分钟的总占用更能对应这项机制。内存充裕能延后资源耗尽，却无法替代修补队列增长路径。
第二项涉及接收侧。非Linux平台使用基于select的套接字监视后端，Linux使用poll；前者即使暂停普通读取，仍监视异常事件，处理事件时又会触发读取，从而绕过原有背压。官方通报将Windows、macOS和BSD列为受到这一问题影响的平台。[2] 它与第一项的共同点是资源限制存在旁路，但发生在不同方向，处置时不能只靠一种连接或队列指标解释全部异常。
Linux不受第二项漏洞影响，这项结论仅限于对应的select代码路径。[2] 将其扩展成“Linux不受此次披露影响”，就会漏掉发送队列与撤销文件的检查。对于混合部署的服务，同一套版本号清单应附上系统信息；否则，负责应用的人可能把Linux的判断误套到Windows钱包节点，也可能把另一条路径引起的异常错误归因于这项漏洞。
相关下载： Binance全球顶级交易所 v3.22.3大小：306.0M
撤销文件的风险，不能用普通重启解决
第三项通报需要更谨慎地阅读。节点在链重组时要撤销区块，恢复被花费的输出，因此区块文件之外还保存撤销数据。官方说明，区块文件上限为128MiB，但对应撤销文件没有相同的大小上限；旧实现用32位整数记录文件位置，越过4GiB时可能回绕，覆盖已有撤销数据。[3] 这里的问题在本地数据记录和恢复路径，不能直接改写成私钥被窃或比特币已经发生通胀。
回绕带来的损坏不一定马上暴露。在需要撤销受影响区块时，节点才可能无法读取所需数据并关闭。官方还说明，旧的Windows及32位文件定位调用存在2GiB限制，可能更早在写入阶段失败，不必等到重组。[3] 因而“最近还能同步”和“重启后能运行”不是等价的验收结果：前者只说明当前路径尚未碰到错误，无法证明历史撤销数据可用。
这项漏洞被官方列为低危，并明确认为实际利用不现实。其描述的64位攻击条件包括大量非标准交易区块、精确的本地文件布局和特定重组配合；不同节点的文件排布又不一致。[3] 这些约束必须保留。把理论上存在的损坏路径写成全网节点随时会被统一击倒，会夸大威胁；因为利用困难而完全跳过修复与恢复准备，也忽略了本地数据出错后的服务成本。
补丁修的是位置宽度，文件系统限制另算
修复将区块及撤销文件位置改为64位整数，并在Windows上采用64位文件定位调用。通报同时说明，位置原本使用可变长度整数序列化，因此磁盘格式不变。[3] 这解释了修复可以改变内部边界而不必改写全部文件格式，但不能据此推断所有存储环境都获得同样效果。
32位系统和把区块目录放在FAT32上的节点，升级这些版本后仍存在通报所列限制。[3] 检查对象应当是实际区块目录所在的文件系统，而不是仅看操作系统名称。64位主机也可能把数据放到不合适的存储卷上；版本符合要求、主机架构符合要求与文件系统符合要求，是需要分别确认的条件。
通报对已经损坏的撤销数据给出明确恢复要求：反复重启没有帮助，需要用修复后的版本重新索引。[3] 据此，支付或查询服务应把恢复时间视为验收的一部分。本文没有执行恢复测试，也没有测量索引耗时；实际耗时取决于本机数据和资源，不能拿一个未经测试的统一时长承诺服务恢复。对有持续查询需求的团队，更有用的是确认备用数据源及切换条件，避免主节点重建期间所有查询一起中断。
相关下载： 欧易okx交易所 v6.195.1大小：549.4M
这次修好了，不代表旧分支会一直获得维护
三份通报都列出了29.5、30.4、31.2与32.1，时间线记录31.2和32.1在10月27日发布修复，29.5和30.4在10月28日发布修复。[1][2][3] 这些信息适合核对本轮补丁是否存在，但不应被读成今后所有旧分支都会持续提供安全更新。
32.1发行说明同时写明，29.x及更旧版本进入维护终止阶段，不再接收更新。[4] 两件事可以同时成立：29.5获得了这轮修复，而29.x后续不再是长期维护目标。运营者若暂时留在已修补的旧分支，应记录迁移期限和兼容性验证，而不是让本轮修复完成成为无限期搁置升级的理由。反过来，新主版本可能牵涉依赖与业务接口变化，升级计划也应包含应用侧验证，不能用安全标签替代完整验收。
发行说明还指出，32.0虽已打标签，却因最后阶段的问题没有完整公告或发布。[4] 因此，资产台账应写清实际安装包与正式发行状态，不能只从仓库标签推断已经完成生产部署。对这次事件，能够复核的证据应落到运行版本、系统、架构、区块目录和恢复方式，而非某个项目曾经发布过公告。
披露速度背后，是漏洞被再次发现的可能性
三项通报的署名均记载了Project Loupe自动扫描发现问题、再由Gregory Sanders验证并提交给Bitcoin Core团队的过程；其中部分问题还有独立再次发现的记录。[1][2][3] 这些记录能支持发现与人工确认的链条，不能证明某一种扫描方法覆盖了全部缺陷，也不能把发现者的工具直接视为生产代码的审批者。
官方安全政策对“容易发现”的漏洞另作处理：尽快为维护中的主要版本提供修复及通报，不适用通常按严重程度设置的保密等待期。[5] 其操作含义是，运营者应关注自己使用的正式分支和安全公告，不能以“低危通常会延后披露”推断还有固定缓冲时间。严重程度描述损害与利用条件，披露安排还要考虑外部再次发现问题的可能性，两者回答的问题不同。
截至本次核对，本文取得的是官方漏洞描述、修复版本及维护政策，没有全网升级比例、实际攻击发生率或服务商停机统计。因而判断止于节点运营边界：内存限制是否有旁路、存储条件是否满足修复假设，以及数据损坏后能否恢复。完成这些核对之后，再讨论自己的业务连续性；通报本身不足以支持币价方向、资金失窃或全网已经发生故障的结论。
用户评论