Bitcoin Core本周动态 - 第29期

INSIDER 发布于 2026-02-06 阅读 60

本文是Bitcoin Core开发周报第29期,报道了近期的合并PR和IRC会议纪要。合并PR包括CWallet::Create()的重构、移除coinbase中dummy extraNonce的修改以及修复日志噪音。IRC会议讨论了网络分割、集群内存池、基准测试、v31版本冻结及Erlay协议的未来。文章提供了比特币核心开发的实时动态和技术细节。

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

上周比特币动态

本期比特币核心动态 - #29

比特币价格暴跌,但这并未阻止比特币核心开发者们……

哈喽 👋 各位,我是 kevkevin。我是一名开源开发者,也是 Insider Edition 的记者。上周,我审核了 Bitcoin Core 仓库中的几个 Pull Request。以下是我认为值得关注的。

已合并的 PR
每周都会有若干变更被正式添加到 Bitcoin Core 中。本周共合并了 29 项更改。以下是本周我认为有意思的一些。

这个 PR 的优势在于,CWallet::Create 曾使用一种糟糕的启发式方法来猜测是应该创建新钱包还是加载现有钱包。该启发式方法假设没有 ScriptPubKeyMan 的钱包正在被创建,但在 #32112#32111 这两个问题中,事实并非如此。

  • mining, ipc: 在 coinbase 中省略虚假的 extraNonceSjors 提交。此项更改在使用 mining IPC 接口时,移除了默认包含在 coinbase 的 scriptSig 中的 extraNonce。这简化了下游挖矿软件(如 Stratum v2),因为现在软件无需包含自定义逻辑来从 scriptSig 中剥离该数据。

此外,这似乎仅针对 IPC 接口,因为 RPC、test、regtest 和内部挖矿的现有行为得以保留。

  • fees: 修复嘈杂的刷新日志ismaelsadeeq 提交。这是一个直接的 PR,它将刷新日志更新为使用 estimatefee 类别的调试级别日志。这样做是因为该日志可能会变得有点嘈杂,我们更希望将其隐藏在调试 estimatefee 类别中。

日志更改可能很枯燥,因为它们不会对用户产生太大影响,但如果做得恰当,能让开发者更容易调试。

总有许多变更在不断更新和实时审核。以下是一些仍在等待审核的值得关注的 PR。

这消除了我们对 boost::signals2 的依赖,使得 boost::multi_index 成为 bitcoind 唯一的 boost 依赖项。

boost::signals2 是一个复杂的庞然大物,但我们只使用了它的一小部分功能。具体来说:它是一种允许多个订阅者连接到同一事件,并能够在之后断开单个订阅者与该事件连接的方式。

btcsignals 遵循我们当前使用的 boost::signals2 API 的子集,因此是直接的替代品。我们并没有实现一个我们从未使用过的复杂 slot 跟踪类(在 std::function 出现之前它更有用),而是将回调直接包装在 std::function 中。


IRC 会议记录
每周四有一次 IRC 会议。以下是该会议的简短记录。
16:02:43 <fjahr> #topic 网络分裂工作组更新 (cfields)
16:03:03 <cfields> 我这周被 boost::signals2 替换的事情分心了,仍然没有网络分裂的更新 :(
16:03:18 <cfields> 我发誓总有一天我会更新的 :)
16:03:29 <fjahr> #topic 集群内存池工作组更新 (sdaftuar, sipa)
16:04:02 <sipa> 重点仍然是 #34257,我认为它已经准备好审核了。
16:04:27 <sipa> 而且我认为把它纳入 31.0 版本很重要,这样我们就不需要在后续版本中更改内存池排序了。
16:04:46 <sipa> #34023 也是如此,它也已经准备好了。
16:05:14 <sipa> 我正在处理 #34138,我认为如果这三个 PR 不再进一步拆分,我们就可以宣布集群内存池**完成了**。
16:05:23 <sipa> 这就是我的情况。
16:05:24 <fjahr> 应该有人把 #34023 加入里程碑 :)
16:05:43 <fjahr> #topic 基准测试工作组更新 (l0rinc, andrewtoth)
16:06:33 <andrewtoth> 正在为 #34165 获得一些审核意见,这就是我的情况。
16:07:33 <sipa> andrewtoth: 我会尽快进一步审核
16:07:57 <fjahr> #topic v31 功能冻结将在三周后开始
16:08:04 <fjahr> - 发布计划:#33607
16:08:05 <corebot`> https://github.com/bitcoin/bitcoin/issues/33607 | 31.0 发布计划 · Issue #33607 · bitcoin/bitcoin · GitHub
16:08:14 <fjahr> 里程碑:https://github.com/bitcoin/bitcoin/milestone/74
16:08:33 <fjahr> 有什么要添加或删除的吗?虽然我做不到,但希望有人会做 ;)
16:09:07 <andrewtoth> #34329 - 我们正在发布静默支付,但没有调试日志。没有这个,我们将难以帮助用户排除故障。它还能让我们收集统计数据。
16:09:51 <furszy> 静默支付是另一个怪兽
16:10:05 <andrewtoth> #33512 修复了在使用高数据库缓存值时出现的大量不必要警告,因为我们现在刷新了很多数据并且没有清除
16:10:14 <andrewtoth> furszy: 谢谢,我就是这个意思
16:12:41 <fjahr> 还有其他人想添加什么到 v31 里程碑中,或者对发布有其他评论吗?
16:15:13 <fjahr> #topic 迟到的提议会议主题 (marcofleon)
16:15:29 <marcofleon> 啊,终于来了。先为下面的一大段文字道歉
16:15:41 <marcofleon> 我最近一直在思考 Erlay,想听听大家的看法。根据我掌握的信息,我倾向于给出 NACK。我不认为其权衡是值得的。据我所知:
16:16:03 <marcofleon> 优点:更多的交易中继(完整中继)出站连接,而数据发送/接收的增加不成比例。我们可以将完整中继出站连接从 8 个翻倍到 16 个,而带宽不会翻倍。
16:16:13 <marcofleon> 缺点:整个网络的延迟增加。在某些模拟中,延迟几乎翻了一倍。此外,Erlay 对 P2P 代码的更改相当广泛,即增加了复杂性。
16:16:25 <marcofleon> #28463 正在研究增加仅区块中继连接。我认为那边的最终目标是拥有 8 个这样的连接。我不清楚拥有超过 8 个完整中继连接是否真的能给网络带来很大的好处。我们已经有相当好的交易抗审查性,因此更多地关注仅区块中继连接以获得更好的日蚀攻击防护似乎
16:16:25 <marcofleon> 更为有益。我愿意改变这个结论。
16:16:46 <marcofleon> 基本上就是想评估一下这个项目,并试图弄清楚我们在这件事上的立场。当然我们不需要现在就有答案,但某个时候(今年?)最好能有一个优先级的 ACK/NACK。如果我们大致同意在可预见的将来不会推进它,那么最好移除任何已合并的 Erlay 相关代码,并专注于增加区块中继
16:16:46 <marcofleon> 连接。如果我们最终决定权衡是值得的,并且开发者的时间应该花在 Erlay 上,那么我会很乐意参与开发/审核并让它成为现实。这绝对是一个优雅的想法。
16:18:20 <sipa> 这是一个很好的讨论话题。我同意我们应该决定要么推进并优先处理,要么完全取消。
16:19:54 <instagibbs> 一个新议题来展开讨论是否是个好的开始?一份总结可能对那些(举手)没有密切关注这个想法随时间演变的人有帮助
16:20:07 <marcofleon> 现在不需要结论,我现在只是提出来。我们可以把它记在心里
16:20:28 <lightlike> 平心而论,Erlay 在最近试图通过阻止交易到达矿工来审查交易(Knots)的尝试中变得更有相关性。尽管门槛已经相当低了(约 10%)
16:20:59 <marcofleon> instagibbs: 在一个议题中重新讨论概念可能不错
16:21:14 <furszy> sr_gi[m] ^^
16:21:20 <fjahr> 同意进行讨论是好的,我也想知道最近有什么进展。
16:21:30 <Murch[m]> 我认为 AJ 关于同步内存池顶部的提案在这个背景下也很相关
16:22:00 <willcl-ark> sr_gi[m]: 最近也重新运行了模拟,如果能在这样一个总结议题中展示出来可能会很好
16:23:17 <stickies-v> lightlike: 我认为新的私有广播机制在这方面也可能有用,可以更积极地进行交易广播?
16:23:18 <sipa> 我认为创建一个新的议题,包含概念讨论、权衡和最新进展,会很好
16:23:50 <sipa> stickies-v: 这在我看来是基本正交的,因为它只涉及最初的公告
16:24:12 <marcofleon> 很好,听起来不错。我们也可以在那里获得最近的更新。我知道这是一个大项目,模拟和测试是其中的重要部分,所以彻底很重要
16:24:47 <sipa> 内存池同步的想法可能很重要——有了它,我们或许可以容忍在扇出+重组后更低的可达性保证,因为稍后可以通过内存池同步来修复
16:24:49 <stickies-v> 但能够向更多对等节点公告似乎应该有助于到达更多矿工?
16:24:56 <marcofleon> 我的想法基于去年看到的模拟,也许情况有所变化
16:25:05 <stickies-v> (还没有想清楚,只是突然想到)
16:25:40 <sr_gi[m]> 我最近在私有广播合并后重新基改了代码。我同意 marcofleon 的看法,我们应该就推进还是取消做出总体决定。如果大家有兴趣,我很乐意就所有权衡和待办事项做一次回顾,并且如果大家对审核代码有兴趣,我会推动进展
16:26:41 <marcofleon> 听起来不错
16:27:11 <marcofleon> 那我们可以开一个新议题。谢谢大家
16:27:35 <fjahr> 谢谢 marcofleon!还有什么其他要讨论的吗?

发布
  • 本周无

感谢阅读。请务必下周再次关注比特币核心的最新动态!

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

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

相关文章

0 条评论