v31.0rc1 标记——比特币核心本周动态第34期

（略去原文，直接输出润色后的已发布内容）
bitcoin++ 是一个国际比特币开发者会议系列。“内部版”是我们的新闻编辑室，报道 bitcoin++ 世界内外的动态。

上周比特币动态

v31.0rc1 已标记 - 本周比特币核心 #34

本周，kevkevin 带你回顾合并到比特币核心的变更……

大家好 👋 朋友们，我是 kevkevin。我是一名开源开发者，也是 Insider Edition 的记者。上周，我审查了比特币核心仓库中的几个拉取请求。

已合并的 PR

每周都会有一些变更正式添加到比特币核心中。本周共合入了 49 个变更。以下是我认为本周比较有趣的一些。

• cli: 重构 -addrinfo 命令行以使用未经质量/新近度过滤的地址 by stratospher

这个变更自 2023 年起就在进行中，最终被合并了。如果你之前没有关注过，这里简要总结一下它的改动。

该拉取请求更新了 CLI 的 -addrinfo 命令，使其返回所有已知地址，而非一个子集。从 v22.0 到 v30.0 版本，返回的集合会按新近度和质量进行过滤。现在这个行为已更改，因为这与选择对等节点时使用的逻辑不匹配，因此本次更新使其保持一致。

如果你使用的是较旧的比特币节点版本，也需要使用较旧的 bitcoin-cli 才能成功使用该方法。

• rpc: 允许将 UTXO 集写入命名管道 by theStack

你是否曾使用过像 AssumeUTXO 这样的 dumptxoutset 功能？

这个变更使得你可以调用 dumptxoutset RPC，然后将其转储到命名管道中。这样，转储的 UTXO 集就可以被另一个进程消费。

TheStack 在 utxo-to-sqlite.py 中使用了这个功能，直接将 UTXO 集转换为 sqlite 文件。我得说这很酷。

他还在完整的 PR 中给出了一个使用示例。

• 线程池: 添加范围 Submit 重载 by andrewtoth

Andrew Toth 在注意到 ThreadPool::Submit 在同时提交多个任务时效率不高，于是促成了这个改动。

原因在于 Submit 方法必须为每个任务获取一个锁。Andrew 解决这个问题的方法是为提交的一批任务获取一个单独的锁。这显著加快了 ThreadPool::Submit 的速度。

总是有变更在实时更新和审查中。以下是一些值得注意的、仍在等待审查的 PR。

• 日志: 重写宏以添加速率限制选项，避免未使用的 strprintf，澄清令人困惑的错误 by ryanofsky

重写日志宏以修复一系列问题：缺乏对速率控制的控制、在模糊测试期间不必要的 strprintf 调用，以及宏参数调用错误时导致令人困惑的错误信息。

此 PR 是一个重构，不应改变外部可见的行为。变更在提交消息中有详细描述。还有一些内部改进，使之前隐式的行为（评估未使用的格式参数，不在某些日志级别输出类别）变得明确并得到更好执行。

这里的一些更改最初是 #29256 的一部分，但它们应该能独立存在，并简化两个 PR。

IRC 会议记录

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

16:01:53 <fjahr> #topic 模糊测试工作组更新 (dergoegge)
16:02:25 <dergoegge> 我这边没什么可说的

16:02:55 <fjahr> #topic 基准测试工作组更新 (l0rinc, andrewtoth)
16:03:12 <l0rinc> 我这边没什么紧急的事
16:03:29 <andrewtoth_> #34576 已合并。#31132 已变基，所有拆分的 PR 都已完成。感谢大家的审查和基准测试！
16:03:33 <corebot> andrewtoth_: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:03:35 <corebot> andrewtoth_: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:03:42 <dzxzg2> 嗨
16:03:56 <andrewtoth_> 我正在考虑重新打开 #31132 作为一个新的 PR，因为已经有超过 500 条评论，其中许多已不再相关。
16:03:57 <corebot> andrewtoth_: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:04:07 <andrewtoth_> 我这边就这些。
16:04:29 <andrewtoth_> corebot 怎么了？
16:04:37 <_aj_> 可能是 GitHub 的速率限制？
16:04:44 <achow101> 估计今天不在状态
16:05:11 <_aj_> （至少我在未登录时经常遇到速率限制，莫名其妙）
16:05:17 <fjahr> 被所有 AI 垃圾搞抑郁了
16:05:20 <fjahr> johnny9dev: 你想重新激活你的，对吧？请编辑工作组的维基页面，谢谢！

16:05:27 <fjahr> #topic QML GUI 工作组更新 (johnny9dev)
16:05:31 <johnny9dev> 是的
16:05:36 <johnny9dev> 对于 gui-qml，我一直在专注于清理对 Qt 源代码的任何依赖。我还一直在致力于测试覆盖和自动化框架。两者都即将完成，届时我将关闭相关的 issue。下周我将与 Luke (epicleafies) 一起开始分块提交功能 PR。目标功能都列在项目的 Issues 中。我还计划花时间学习 Figma Make 和 Figma 的 MCP 服务器。过去两周我看到了一些实际案例非常有效，需要为 gui-qml 探索这一点。
16:05:54 <johnny9dev> 对于 gui，dergoegge 询问测试桥是否适用于 Qt，所以我花了一些时间移植测试自动化桥。它还有点粗糙，需要更多的验证/审查，但我在 bitcoin-core/gui#933 上开始了草案。感兴趣的人可以看看这个方法的想法。端到端测试一开始可能会出现稳定性问题，所以需要努力确保一切稳固，然后再真正推进这样的事情。动画、进程初始化和时序可能比较棘手，但这应该不会比你们在 bitcoind 功能测试中遇到的情况更糟糕。
16:05:55 <corebot> johnny9dev: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:06:00 <kanzure> Figma 能导出到 QML 吗？
16:06:14 <johnny9dev> 你可以使用 MCP 桥来帮助将 Figma 转换为代码
16:06:20 <dergoegge> johnny9dev: 酷，我会看一下
16:06:59 <johnny9dev> epicleafies 也一直在帮助处理 QML
16:07:25 <johnny9dev> epicleafies: 能说说状态吗？
16:08:04 <epicleafies> 是的，我已经完成了调试日志页面，正在处理代理设置以使其持久化
16:08:59 <johnny9dev> 他还完全完成了对等节点的封禁/断开连接功能，包括一个端到端的自动化 GUI 测试
16:09:22 <johnny9dev> 我认为那可能也是最复杂的一个
16:09:26 <johnny9dev> 涉及多个节点
16:10:14 <johnny9dev> 我想就这些了
16:11:19 <fjahr> 我没看到其他工作组的负责人。

16:11:25 <fjahr> #proposedmeetingtopic 日志系统 (_aj_)
16:11:25 <corebot> fjahr: 未知命令: #proposedmeetingtopic
16:11:30 <fjahr> 抱歉
16:11:33 <_aj_> 大约有十几个关于更改日志 API 的开放 PR/问题，其中许多已经开放了将近两年。这里有一个表格：

16:11:25 <fjahr> #proposedmeetingtopic 日志系统 (_aj_)
16:11:25 <corebot> fjahr: 未知命令: #proposedmeetingtopic
16:11:30 <fjahr> 抱歉
16:11:33 <_aj_> 大约有十几个关于更改日志 API 的开放 PR/问题，其中许多已经开放了将近两年。这里有一个表格：https://gist.github.com/ajtowns/ff6247953437270ce81998bc0f7d6739
在我看来，这些更改中的许多实际上让比特币节点软件的开发变得更糟了，到现在我觉得这就像一种拒绝服务攻击：“哦，你不同意这个 PR？好吧，我们把它作为一个达摩克利斯之剑继续开放，但还有这个略有不同、动机也略有不同的 PR 呢？” 这让我只能给出感觉是无穷无尽的“概念 NACK”，并且越来越沮丧。还有 #28318 的一些后续工作我想做（主要是 #34038，完成后切换类别映射为原子位域），所以我宁愿保持一定的参与度，但这让人非常疲惫。所以我真的希望那些对这个话题比较冷静的人能够参与进来，表达一下这些提议的更改是否有价值/值得期待，理想情况下，开放提案的数量能大幅减少。
16:11:35 <corebot> _aj_: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:11:36 <fjahr> #topic 日志系统
16:11:37 <corebot> _aj_: 错误：该 URL 在前 32KB 内似乎没有 HTML 标题。
16:12:01 <achow101> （会议后我会调试机器人）
16:12:26 <_aj_> （结束）

16:12:54 <sipa> #proposedmeetingtopic 我看到 31.0 的发布说明编辑已移至维基（https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Notes-Draft），大家最好都看一下，添加用户应该注意的内容
16:12:54 <corebot> sipa: 未知命令: #proposedmeetingtopic
16:13:09 <sipa> （不算是主题，只是提一下）
16:13:19 <_aj_> （有人宣布过分支已经创建了吗？）
16:13:48 <sipa> 日期已更改为 2026 年 3 月 12 日
16:13:48 <sipa> 01:56:13 < bitcoin-git> [bitcoin] achow101 向 31.x 推送了 5 个提交：https://github.com/bitcoin/bitcoin/compare/b97abdcdf139...d3737769caac
16:14:40 <achow101> _aj_: 关于日志方向的主要观点有多少？2 个？
16:15:03 <fanquake> 我认为 3 个
16:15:08 <fjahr> 看起来有三个 PR 作者
16:15:13 <fanquake> 取决于代码库的哪个部分
16:15:24 <fjahr> （当前活跃 PR 的作者）
16:15:52 <dzxzg2> 如果能简洁地表达，更改接口的不同目标 / 用例 / 动机是什么？
16:16:43 <_aj_> 我认为有几个关于内核的不同观点（如果你运行多个验证对象，它们的日志能否分开；如果你有多个日志记录器和一个验证状态，它们能否获取不同信息）；有人希望向 Log*() 函数传递不同数量的状态（钱包名称、类别、级别中的一部分或全部）；有时还有人希望所有消息都有类别（LogInfo(NET, “连接到新的出站”)）
16:19:10 <fanquake> 粗略统计，我认为目前大约有 15 个不同的日志相关重构 / PR 处于开放状态
16:20:21 <dergoegge> 一些与内核相关的日志问题值得解决，但我不确定命名和调用约定（那看起来是个无尽的时间陷阱）
16:21:16 <_aj_> 内核相关的东西会影响调用约定——如果你希望 CheckBlock 的日志流向两个不同位置，你必须将两个不同的日志系统传入 LogDebug(..) 调用中，例如
16:21:40 <sipa> “两个不同位置”是什么意思？
16:22:19 <_aj_> 如果你在同一进程中运行两个不同的 ChainstateManager，并且希望独立记录它们所做的工作或失败情况
16:23:36 <l0rinc> 这些日志更改建议从根本上说是互斥的吗？
16:23:40 <sipa> 我困惑为什么会出现这种情况，或者相关代码怎么会知道这个
16:23:45 <sipa> 所以我需要看一下 PR
16:23:53 <dzxzg2> l0rinc: +1
16:24:02 <_aj_> #34062 可能是一个好的开始
16:24:04 <corebot> https://github.com/bitcoin/bitcoin/issues/34062 | RFC: separate kernel logging infrastructure · Issue #34062 · bitcoin/bitcoin · GitHub
16:24:11 <_aj_> 欢迎回来，corebot
16:24:15 <abubakarsadiq> 嗨
16:24:27 <l0rinc> 这与不同的钱包和进程记录到不同的输出文件有关吗？
16:25:32 <sedited> 恕我直言，我认为这是一个有更好，但花在日志讨论上的时间相对于让东西真正更有用来说似乎不平衡。我现在满足于一个简单但不完美的解决方案。
16:25:44 <sedited> l0rinc 我认为那是正交的
16:26:40 <ryanofsky> 是的，我认为我们可以很容易地在这些事情上取得进展，只需专注于没有争议的日志 PR
16:28:13 <_aj_> ryanofsky: 关闭那些相近的替代方案，只保留其中“最好的”一个，在我看来是一种胜利（最好==你在考虑反馈后的判断，不一定是争议最小/最可能被接受的；依我之见）
16:29:10 <dzxzg2> https://en.wikipedia.org/wiki/Wikipedia:Content_forks#Pages_of_the_same_type_on_the_same_subject
16:30:20 <l0rinc> 在我看来，日志问题对我们大多数人来说并不明显，它似乎已经在工作了 - 我们可以先列出确切的问题吗？
16:30:21 <fjahr> 当有一个明确的点需要更多反馈时，再在这里请求审查。我觉得很难让自己去通读整个列表并自己找到那个点。
16:31:43 <ryanofsky> 我个人的感觉是，花时间进行关于应该审查什么代码的元辩论并不好，通常人们只需审查他们感兴趣的东西，并维护他们有兴趣维护的 PR
16:32:25 <ryanofsky> 如果某些进展被阻塞了，但我并没有意识到
16:32:47 <fjahr> 看起来日志的细节可以在会议后继续讨论。还有什么需要在会议上讨论的吗？
16:32:53 <_aj_> fjahr: 你可以合理地查看上面的 Gist 并说“这很丑陋，真的有大的好处吗？”或者“这比我们现在做的好多了！我喜欢！”这也会是有用的贡献
16:32:54 <ryanofsky> 同意
16:33:10 <ryanofsky> 是的，我会看一下 Gist
16:33:22 <achow101> fjahr: 31.0 的主题？

16:33:37 <fjahr> #topic v31
16:33:52 <achow101> 我们在周二晚上创建了分支，昨天标记了 v31.0rc1
16:34:00 <_aj_> 好！
16:34:21 <achow101> 有一个回溯 PR，里程碑中还有几件事，所以肯定会有 rc2
16:34:34 <achow101> 有什么新问题需要添加到里程碑吗？
16:35:07 <achow101> 另外，发布说明草案在维基上
16:35:47 <janb84> 测试指南将由 BOSS 项目 / 我负责
16:36:03 <fjahr> https://github.com/bitcoin/bitcoin/milestone/74
16:37:08 <achow101> 否则就这些了
16:37:37 <fjahr> 还有其他主题吗？
16:37:37 <maflcko> 我想在这个版本中修复所有间歇性测试问题，所以如果你发现任何新的，请告诉我 :)
16:37:45 <fanquake> 看起来我刚看到了另一个
16:37:50 <fanquake> https://github.com/bitcoin/bitcoin/issues/34367#issuecomment-4048211050
16:38:03 <fanquake> （发生在回溯分支中）
16:38:22 <fanquake> 我假设我们会在另一次子模块拉取中修复所有多进程问题？
16:38:37 <fanquake> （一旦那里其余的问题被修复）
16:38:41 <maflcko> 或许让功能测试在夜间循环运行，看看第二天早上是否仍在运行。如果没有，就留下一个 issue。（确保为较小的机器增加 --timeout-factor）
16:39:34 <fanquake> 我没有 Windows 机器，所以 Windows 上的某人必须为该问题做这个（可能与 UCRT 有关）
16:40:26 <maflcko> 哦，我是指一般意义上，看看是否所有开发机器和平台都能顺利运行测试
16:40:48 <fanquake> 是的，肯定会运行
16:40:53 <maflcko> 好的，谢谢

发布版本

• https://github.com/bitcoin/bitcoin/tree/v31.0rc1

感谢阅读。请务必下周继续关注比特币核心的更新！

如果有任何评论、建议或错误，请随时联系或评论

• 原文链接： insider.btcpp.dev/p/v310...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～