放弃 MSVC 支持 - Bitcoin Core 本周动态 #54

liumuhui 4小时前阅读数 1 #区块链

文章标签 Bitcoin Core MSVC 编译器钱包迁移 REST API 模糊测试

bitcoin++ 是一个国际性的 bitcoin 开发者会议系列。"Insider Edition" 是我们的新闻编辑室，报道 bitcoin++ 宇宙内外正在发生的事情。

上周比特币动态

放弃 MSVC 支持 - 本周 Bitcoin Core #54

本周放弃了 MSVC 支持...

大家好，我是 Kevkevin。我是一名开源开发者，也是 Insider Edition 的记者。上周，我审阅了 Bitcoin Core 仓库中的几个 pull request。

本周的 IRC 会议上，hebasto 提出了一个简单的问题：我们还需要 MSVC 作为受支持的编译器吗？

发布二进制文件从来都不是用 MSVC 构建的，而是用 MinGW 构建的。在 Windows 上从源码原生构建，是 MSVC 最后仍会出现的地方，而 clang-cl 已经可以在那里正常工作。#31507 将使 Clang 在 Windows 上成为一等公民，也就是从那时起，审阅者开始发问：为什么我们还要为一个无法修补的闭源编译器保留 workaround？

保留它的理由是编译器多样性。但实际上，它发现的 bug 都是 MSVC 自身的 bug，相关补丁已经几乎没人审阅，而且它将成为唯一一个使用三种工具链的平台。在几个 ACK 之后，会议室的结论是"那我们就放弃 MSVC 支持吧"。hebasto 正在开一个 issue，讨论我们应该砍到什么程度。

已合并的 PR

每周，都有若干更改被正式合并进 Bitcoin Core。本周，多项更改被合并。以下是我本周觉得有趣的一些。

rest: add Cache-Control headers to REST responses，作者 w0xlt

本周，w0xlt 的一个 REST PR 被合并，它终于让缓存知道该如何处理 Bitcoin Core 的 REST 响应。在此之前，REST 响应没有 Cache-Control 头，因此位于节点前面的反向代理或 CDN 不知道哪些内容可以安全缓存、哪些内容会过期。

这个策略是刻意保守的。以哈希寻址的不可变数据（raw /block 和 /block/notxdetails 的 bin/hex，以及 /blockpart、/blockfilter、/spenttxouts 和 /deploymentinfo/.json）会被设置为 Cache-Control: public, immutable, max-age=86400。其他所有内容——包含依赖 tip 字段的 JSON 区块视图、/tx、/headers、/chaininfo、mempool、UTXO、错误、未匹配的 404——则一律设为 no-store。

审阅者反对给不可变响应设置一年 TTL。一天的时间足以减轻节点负载，还能避免升级后卡在过时的缓存格式上。希望采用更激进策略的运营者，仍然可以在 nginx 或 CDN 中覆盖这些默认值。

wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain)，作者 w0xlt

w0xlt 还为从 Bitcoin Core v0.14.3——也就是 2017 年——迁移到今天 descriptor 钱包格式的场景补充了测试覆盖，目的是确保用户能够在不丢失资金、历史记录或地址的情况下完成升级。

该测试覆盖了现有迁移测试尚未覆盖到的两种旧钱包类型：使用 -usehd=0 创建的非 HD 钱包，以及那个时代的第一代 HD 钱包（VERSION_HD_BASE，单链）。0.14.3 节点无法使用常规测试框架的同步 RPC，因此测试会在运行迁移之前用 dumb_sync_blocks 把区块喂进去。

它还检查了加密变体，确认迁移不会悄悄加入 rescan，并确认备份是一个真实文件。如果你手头还有那个年代的钱包，这正是你希望 Core 在运行 migrate 之前就具备的覆盖。

总有一些更改在持续更新和审阅中。以下是一些仍然开放、正在寻求审阅的值得注意的 PR。

txindex: hash keys and pack positions to reduce disk usage，作者 andrewtoth

当前的 txindex 使用完整的 32 字节 txid 作为键，在主网上如今大约占用 66 GB 磁盘空间。改用 5 字节键前缀可以将磁盘占用降到 26 GB——大小削减了一半以上。

使用完整的 32 字节是没有必要的，因为 5 字节加盐 siphash 大约在 1.1 万亿分之一的情况下才会产生碰撞。虽然确实会发生一些碰撞，但代价不过是多一次磁盘读取、反序列化和哈希计算。
tx 位置可以追加到键上而不是用作值，LevelDB 迭代器可以定位到前缀，然后扫描找到正确的 tx。这与 txospenderindex 采用的方法几乎相同。

IRC 会议记录

每周四都会举行 IRC 会议。以下是那次会议的一些简短记录。

--- Topic 1 ---
fjahr: #topic Fuzzing 工作组更新 (dergoegge, marcofleon)
dergoegge: 我有一些好玩的东西要分享
dergoegge: 我给 https://github.com/antithesishq/bombadil 鼓捣了一个扩展，可以测试 qml 图形界面
dergoegge: https://drive.google.com/file/d/1ioXLPUTvnxi9oo1gn4Hb6ggHsXVb26KY/view 这是 fuzzer 工作时的视频
dzxzg: 嗨
dergoegge: 我还让 claude 在周末用 fuzzamoto 测试了一个 vibe coded 的节点实现（rbitcoin）
dergoegge: 它发现了很多 bug：https://github.com/reardencode/rbitcoin/tree/master/docs/external_findings（其中几个来自 red team，其余来自 fuzzamoto）
dergoegge: 这并不是想贬低这个实现，但这或许会增加人们对 fuzzamoto 能发现哪些类型 bug 的信心
dergoegge: 我觉得里面也有一些好笑的
dergoegge: 就这些了
dergoegge: 其实我觉得 eugene 也有东西要分享
eugenesiegel: 嗨，是的
eugenesiegel: 我一直在为 fuzzamoto 做一种叫增量快照（incremental snapshots）的东西，并写了一篇关于其基准测试的简短博客文章：
eugenesiegel: https://crypt-iq.github.io/2026/08/07/incrementalsnapshots.html
eugenesiegel: 它基本上是一种加速 fuzzer 并聚焦更深代码路径的方法
dergoegge: 
eugenesiegel: 就这些，如果有任何问题或不清楚的地方，请告诉我
marcofleon: lfg
brunoerg: 不错
sipa: 真酷

--- Topic 2 ---
fjahr: #topic Benchmarking 工作组更新 (l0rinc, andrewtoth)
l0rinc: #35531 已经准备好可以审阅了，我觉得它和我们在这个版本里做的其他优化会很搭配
l0rinc: 好消息是，我对 bitcoindev1337 提出的在连接前预取区块的想法做了基准测试，它确实显示出显著的加速，超过了我估计的 5%，所以值得更深入的研究！
l0rinc: bitcoindev1337，你是想自己提交点什么，还是希望我们来做？如果是后者，你的 github 用户名是什么，好把你加为共同作者？
l0rinc: 我就这些

--- Topic 3 ---
fjahr: #topic QML GUI 工作组更新 (johnny9dev)
johnny9dev: 上周我们收到了大量关于预览版的反馈，并已经开始处理这些问题。项目看板仍将是我们跟踪工作进度的地方。
johnny9dev: 我们目前大约有 80 个 issue 需要在开始 PR 之前完成，还有大约 20 个我们认为在它可以发布之前需要完成。
johnny9dev: 我觉得在当前 staging 分支上得到的反馈/印象已经足以让我决定改变路线。我现在正着手从我们现有的最佳版本出发，分阶段构建这个应用。这将包括从一开始就引入我们所有的测试框架。各个阶段将与项目当前的 git 历史非常相似。
johnny9dev: 1. 引入构建和 main  2. 添加第一个节点生命周期和模型  3. 添加入门引导、设置和节点运行功能  4. 添加桌面钱包创建  5. 添加发送/活动/接收……最后几个阶段将为应用添加功能页面。
johnny9dev: 这应该会让历史更干净、更容易审阅。我会努力让每个提交都标注所有涉及的贡献者。
johnny9dev: 等我更接近完成时，我想我会在 bitcoin/bitcoin 中创建一个包含计划的 issue，并跟踪我们需要完成的所有步骤，然后着手为第一部分发起 PR。
johnny9dev: 这周就这些

--- Topic 4 ---
fjahr: #topic QA 工作组更新 (brunoerg)
brunoerg: 大家好，我已在 https://bitcoincore.space 发布了针对 src/psbt.cpp 和 src/private_broadcast.cpp 的最新分析。另外，我还花了一些时间筛选 src/script/interpreter.cpp 中存活下来的 mutants，所以存活下来的那些可能就是最值得处理的。就这些，谢谢。
fjahr: 工作组就这些

--- Topic 5 ---
fjahr: #topic 编译器多样性：放弃 MSVC 还是保留？(hebasto)
hebasto: 嗨
hebasto: 在 Windows 上，和大多数其他系统一样，可以用来构建 Bitcoin Core 的编译器不止一个。
hebasto: Clang 提供了 clang-cl.exe 工具，它与 MSVC 的 cl.exe 兼容。在涉及共享的 libbitcoinkernel.dll 时，后面这一点很重要。
hebasto: 虽然现在就可以使用 clang-cl.exe，#31507 进一步改善了构建体验，并使 Clang 在 Windows 上成为一流支持。
hebasto: 在某个时候，审阅者提出，可以完全放弃对生成二进制质量较差的 MSVC 的支持。
hebasto: 放弃 MSVC 支持有很多好处，但缺点是会降低测试 Bitcoin Core 代码库的编译器多样性，cfields 在上一次 CoreDev 上指出了这一点。
hebasto: 这就是今天会议的问题：
hebasto: 我们还想保留 MSVC 作为受支持的编译器吗？
purpleKarrot: 这个需要投票吗？
cfields: 我觉得这取决于"支持"的含义。
fanquake: 我觉得这事被提出来也是因为 #31507（它会放弃 MSVC）被标记为 32.0 的目标，但同时还有像 #24773 这样的 PR 在开放中，会增加更多 MSVC 特定代码。
fanquake: 同时有 PR 在放弃对一个东西的支持，又有 PR 在增加对它的支持，这让人困惑。
hebasto: 我说的支持是指针对编译器 bug 的 workaround 和 MSVC 特定的诊断。
purpleKarrot: 我理解的支持是，当使用 MSVC 作为编译器时，代码能够构建、测试能够成功运行，这是一项要求。其他一切（针对 bug 的 workaround 等）都是这项要求的下游。
cfields: 我觉得停止针对非 (gcc|clang) 的构建/测试会是一件遗憾的事。我认为"我们是否应该因为 MSVC 不支持 X 而避免做某些优化"是另一个问题。
hebasto: 注意，clang-cl 仍然使用微软的标准库。
fanquake: 我们也不想陷入那种"nightly"支持循环：没有真正的 CI 在跑，我们还得在事后不断重构/修改代码去支持某个东西。
fanquake: （类似于我们最近在所有 BSD 上看到的情况）
hebasto: fanquake：不过我们可以在主仓库里保留一个 MSVC CI 任务。
dzxzg: 如果主仓库里保留一个 MSVC CI 任务，那我们对 MSVC 的支持会有什么变化？
cfields: hebasto：那你能准确描述一下你说的放弃支持是什么意思吗？明确允许 MSVC 构建失败？把 MSVC 的 ifdef 都拆掉？
cfields: 我这么问是因为目前发布构建是 mingw。所以严格来说，对用户而言，MSVC 已经是"不受支持"的了。
hebasto: https://github.com/bitcoin/bitcoin/pull/31507/changes/96d2380dc40e703e342dc0fad5d294cc49b25ff9 会从构建系统中移除 CI 任务、文档和 MSVC 特定的诊断。
hebasto: 是的，这与发布二进制文件无关。
hebasto: 但我们支持在 Windows 上从源码构建。
cfields: 我仍然认为失去这种多样性很可惜。但这话说起来容易，毕竟我不是那个为了保持 MSVC 能编译而干活的人。
cfields: *diversity
hebasto: fanquake：你同意保留当前的 MSVC 支持吗？
cfields: 也许可以找个中间地带，让一部分构建保持可用？kernel？bitcoind？
fanquake: 我不太在意。如前所述，这并不会实质性地改变我们的发布二进制文件，但这也是一个反对的理由，因为 31507 是在添加对 clang 的支持，也就是为 Windows 编译增加**另一种**方式（新的 CI 任务、更多的构建复杂性等），却没有实际改进我们发布的任何东西。
fanquake: 这里也有一些反对意见：https://github.com/bitcoin/bitcoin/pull/31507#issuecomment-3928937728
sedited: 它将成为唯一一个我们支持用三种不同工具链来构建的平台。
hebasto: 嗯，对于那些喜欢在 Windows 上从源码构建的人来说，clang-cl 生成的二进制要好得多。
fanquake: 基本上，如果使用 clang 的动机是为了避开所有 MSVC 编译器 bug/ICE，那我们为什么还要继续带着所有这些包袱去支持/测试它呢？
fanquake: *why are we
fanquake: 尤其是考虑到，在我们使用的所有编译器中，它是唯一一个我们实际上无法修复的。
fanquake: （无法向上游提交补丁，微软论坛对支持类 bug 几乎毫无用处等等）
purpleKarrot: 我们不应该把两个不同的话题混在一起。我们想用能生成最好二进制的编译器来构建发布二进制文件。同时我们也想要多样化的测试环境来发现代码中的问题。
cfields: sedited：说得好。而且关注它的人最少。
fanquake: purpleKarrot：据我所知，到目前为止我们用 MSVC 发现的问题，都只是编译器自身的 bug。
fanquake: 我不确定构建发布版本的最佳编译器是什么，但它必须是开源的。
cfields: fanquake：嗯，好吧，我撤回我的反对意见。我想这在如今更多是一种哲学上的坚持，缺乏现实基础。它可能多样，但也确实很烂 :p
dzxzg: +1，虽然编译器多样性很好，但 MSVC 是出问题时最不透明的一个。MSVC 有可能捕获到原本会被忽略的问题，这种不确定但可能的收益，很难与实际且持续的维护成本权衡。
sipa: （只跟了一半，我在旅途中）我觉得把"支持"分成两个不同级别是有意义的：(1) 我们发布的 release 二进制所用的东西；(2) 我们认为人们应该能够为其构建的系统/平台，但没有测试保证。例如，我觉得一些 BSD 属于第二类。
sipa: 而且 (2) 也有助于测试多样性，但不需要专门为其优化。
fanquake: sipa：当然，但那会维持那种合并的循环，并且不得不持续重构/修复代码。
fanquake: 故障在事后才被报告。
fanquake: 浪费审阅者时间，并制造动荡。
fanquake: 也许这样也没关系，构建可以在那些平台/CI 中继续保持损坏状态，直到有人想回过头来处理它。
jonatack: 嗨
janb84: 如果它不能提供新的代码问题/见解，只会带来需要 workaround 的编译器问题/bug，我看不出它给我们带来了什么。
hebasto: cfields：我是不是可以这样理解——你不再反对放弃 MSVC 支持了？
sipa: fanquake：或者我们可以选择把 MSVC 视为连 (2) 都算不上？
fanquake: （也许我们应该在仓库的 CI 中多加一些任务）
sipa: 我想甚至可以有更细粒度的级别，例如"这个配置没有 CI，但我们接受修复它的补丁"。
hebasto: ^^ 这看起来合理。
cfields: hebasto：至少不是出于从多样性中获益的理由。
lightlike: 我们知道是否有用户/开发者用 MSVC 构建（并且在出问题时倾向于抱怨），还是说只是 CI 在用？
stickies-v: 接受补丁但不在 CI 中运行，说实话对我来说似乎是两方面的缺点都占了。
dzxzg: lightlike：我们确实有一些，因为目前它是唯一受支持的 Windows 构建系统，但我估计在 clang-cl 支持被合并并用于构建说明之后，这个数字会接近 0。
hebasto: lightlike：我在 Windows 上从源码构建，但我更喜欢 clang-cl。
sedited: 是的，MSVC 补丁已经几乎没人审阅了。CI 中没有它之后，这个数字可能会降到零。
cfields: dzxzg：嗯？它不是唯一支持 Windows 的。
dzxzg: *我说的是原生 Windows，不是 WSL 或交叉编译。
sipa: stickies-v：我认为这就是比如 FreeBSD 的现状，或者至少过去是这样；我更多是在试图描述当前现实，而不是在建议一项政策。
fjahr: 我们接下来 2-3 分钟内把这个话题收个尾，可能会在会后继续讨论。
stickies-v: 如果它不能帮助我们捕获很多 bug、使用得不多、而且是一个闭源又难用的工具链，那么完全放弃支持在我看来是合理的。不过我并没有真正参与其中，所以如果有人想支持它，我也没意见。
hebasto: 是否可以保留对 MSVC 和 clang-cl 各一个发布周期的支持，然后以后再决定？
hebasto: * clang-cl
sipa: 嗯
cfields: stickies-v：+1。我想我现在也认同这个看法了。如果它是开源的、我们能够改进它，情况会不同。但考虑到未来我们（例如）迁移到 c++26，很难想象支持 MSVC 对我们有什么好处，只会拖慢我们的步伐。
fjahr: sedited：你还想给 kernel 做个更新吗？
sedited: 今天不了
hebasto: 那我们就放弃 MSVC 支持吧
sedited: ack
janb84: ack
stickies-v: 也许可以为此开一个 issue？
cfields: hebasto：不如开一个带有具体提案的 issue，我们在那里继续讨论如何？
hebasto: 我会开的
cfields: 我还不清楚你提议我们具体放弃到什么程度。例如，把 CMake 里的相关东西全部拆掉，意味着再也没有人能**尝试**构建它了。
fjahr: 抱歉，让我挤进我的小话题，讨论在 issue 里继续吧 :)

--- Topic 6 ---
fjahr: #topic Kartograf 0.5.0 (fjahr)
fjahr: 大家好，我们发布了 kartograf 的新版本 v0.5.0。最大的消息是有两个 bugfix 会破坏可复现结果，因此使用这个新版本，你将无法复现用旧版 kartograf 创建并包含在 asmap-data 仓库中的地图。因此我提议在 asmap-data 仓库中加一个说明，让用户意识到这一点：
fjahr: https://github.com/bitcoin-core/asmap-data/pull/67 过去我们看到很多用户直接使用 master，这可能会在未来导致一些误报。
fjahr: 再提供一些信息帮助大家理解影响：这两个 bugfix 是 1. https://github.com/asmap/kartograf/pull/145 合并代码中的一个 bug，当地图的更高优先级输入中已经存在较长前缀时，较短前缀无法被合并。这意味着修复后，在相同输入下结果会有更多条目和更大的覆盖范围，但新增的覆盖范围看起来大多是未使用的地址空间，
fjahr: 这些地址空间包含在 IRR 数据库中，所以对我们的目的而言，实际影响似乎很小。在最近 5 张历史地图上，对比特币网络的影响是，有 3-4 个之前没有映射关系的 peer 使用新地图后有了映射。Joris 的更详细分析请见这里：&lt;>
fjahr: 2. https://github.com/asmap/kartograf/pull/148 我们下载的 IRR 数据库格式不一致，由于我们预期它们总是以空行结尾，有时当不是这种情况时，最后一条条目会被跳过。在最近的运行中，这仅仅导致最终文件中多出（如果有的话）一个前缀映射，比特币节点的映射没有受到影响。
fjahr: 另外，我之前说过我认为发布对我们没有意义，因为参与者通常只是用 master，但在这种情况下它让沟通容易得多，所以我想我们暂时不会放弃发布。
fjahr: 欢迎就此提供反馈。当然，我们还对代码库做了一些额外的（AI 辅助）审查，以确保我们没有遗漏任何其他我们想要一起打包的破坏性更改。但我们没有找到其他东西。
fjahr: 很抱歉倒了一大段文字，但 kartograf 仓库没有太多人关注，所以我宁愿直接放在这里。
sipa: 这些更改之后，我们是否会期待 kartograf 输出有更多一致？
sipa: （在所有运行 0.5.0 的参与者之间）
fjahr: 据我所知，这应该无关。不一致通常来自 rpki，而这些更改对 rpki 没有影响。
sipa: 好的
fjahr: 我们仍然不知道最近不匹配率上升的确切来源，但最近一次有所改善，所以我们在下载步骤中做的小改动可能有所帮助。
fjahr: 最近一次是 7/10 匹配。
sipa: 不错
fjahr: "我的代码不工作，我不知道为什么；我的代码能工作，我不知道为什么"
fanquake: 下一次 asmap 运行很可能会被包含在 32.0 中吗？
fjahr: 是的，我觉得问得正是时候：feature freeze 还有 1 周。对此有什么最后一刻的评论吗？
sipa: 新的 asmap 数据算功能特性吗？:)
fanquake: 我觉得新的 asmap 数据更像 chainparams 之类的东西。
fanquake: 所以在分支之前做就行。
fjahr: 是的，不是那个意思，不过我忘了为这个话题留出空间 :)
sipa: 另外提醒一下，我明天休假回来，我希望还能为 32 做些有价值的审阅。

点击这里阅读完整会议记录