Bitcoin Core 功能冻结临近，变基问题影响未加密连接提案

Bitcoin Core，作为运行 Bitcoin 节点的顶级软件客户端，计划于 Thursday, Aug. 20 进入 v32 功能冻结阶段。截止日期将发布重点转向漏洞修复，并为新的 v32 功能在项目 10 月发布目标前提供最后的常规窗口。

截至 Aug. 17，v32 milestone 列出了 17 个未完成项目和 79 个已完成项目，工作进度为 82%。这 17 个条目涵盖了功能拉取请求、漏洞报告、构建与日志记录工作、私有广播测试失败，以及发布时间表条目本身。GitHub 不会对队列进行阻碍项（blocker）排名，因此原始计数更多地反映了未完成的范围，而非发布风险。

根据proposed schedule，源语言翻译字符串也将在 Thursday 冻结。维护者随后计划于 Sept. 10 分离 32.x 分支并发布 v32.0rc1，同时新的 v33 工作将在 master 分支上恢复。标记 v32.0 的目标日期是 Oct. 10。

Bitcoin Core v32 冻结改变了仍可进入发布版本的内容。错过 Thursday 的功能拉取请求将不再走常规的 v32 路线，而符合条件的修复程序仍可在发布 rc1 之前接受审查。未完成的里程碑条目可能代表发布管理、冻结后仍符合条件的漏洞，或者面临 Thursday 截止期限的未完成功能代码。

两项未完成的更改已经显现出集成摩擦。一项允许操作员reject unencrypted v1 outbound clearnet connections的提案，以及一项limit simultaneous HTTP clients的更改，均带有 “Needs rebase” 标签。该标签意味着补丁已无法直接应用，使其优先级和最终是否纳入仍未解决。

钱包相关工作具有直接的兼容性后果。在报告了upgrade-related load failure后，一项未完成的descriptor-wallet fix提案建议，当重新计算的描述符标识符与存储记录不同时，应保留对现有 Miniscript 钱包的访问。另一份 Aug. 12 report 描述了从 v29.2 升级到 v31.1 后出现的钱包错误。该单一案例确证了所报告的故障，但其普遍性、原因和发布优先级尚不明确。

费用估算提案将仅使用内存池（mempool）数据来lower the existing block-policy recommendation，旨在减少超额支付，同时保留估算器较高的安全上限。私有广播工作重点在于controlling rebroadcast-related state growth；另一项v1 retry-test failure仍留在里程碑中。

Thursday 将决定哪些功能更改能通过 v32 关卡，哪些将继续向 v33 推进。漏洞修复在发布候选（release-candidate）周期内仍符合条件。该时间表涵盖了 Bitcoin Core 软件的打包和测试；共识规则的激活不在此文档记录的 v32 发布计划之内。