Bitcoin Optech 周报 #423 回顾播客
节点原本要保存约 11 GB 的 UTXO 集,而 Utreexo 的累加器不足 1 kB,Davidson Souza 在 #423 回顾节目中解释说,代价是占用更多带宽。MARA 的 Eric Price 和 PortlandHODL 也来做客,议题还有让降速矿工陷入困境的 vardiff 控制器,以及不可花费内部公钥的 BIP 草案。
Bitcoin Optech
从官方来源收录的全部内容。
141 篇文章
节点原本要保存约 11 GB 的 UTXO 集,而 Utreexo 的累加器不足 1 kB,Davidson Souza 在 #423 回顾节目中解释说,代价是占用更多带宽。MARA 的 Eric Price 和 PortlandHODL 也来做客,议题还有让降速矿工陷入困境的 vardiff 控制器,以及不可花费内部公钥的 BIP 草案。
Bitcoin Optech
Eric Price 在 Delving Bitcoin 上指出,矿工速度变慢后,矿池可能仍按原来的速度设定份额难度,把矿工晾在一边;他的办法是设一个计时器,一段时间没有提交份额就下调难度。Davidson Souza 希望用 SwiftSync hintsfile 省去初始区块下载期间的 Utreexo 删除证明,NTL 则起草了不可花费 Taproot 内部公钥的 BIP。
Bitcoin Optech
Adam Gibson 向 Optech 主持人 Mark Erhardt 和 Mike Schmidt 介绍 Babilonia,他把 CoinJoin 伪装成秘密赌局的协议,并提到 Ron Rivest 1997 年关于彩票式微支付的论文,视其为概率支付的早期源头。Rob Segers 随后谈他对静默支付轻客户端的测量结果。
Bitcoin Optech
Babilonia 是 Adam Gibson 的新提案,把 CoinJoin 包装成链上抛硬币,外人看来与普通支付无异,不过他的论文也承认,协议效果目前还没有明确的衡量标准。Rob Segers 的基准测试显示,BlindBit Oracle v2 的下载量约为仅含 Taproot 的过滤器加 tweak 数据的 2.1 倍,换来的是零误报。LDK v0.2.6 修补了一个拒绝服务漏洞。
Bitcoin Optech
运行时磁盘读写居高不下,根源是 chainstate 数据库反复重写自身大片内容,Bitcoin Core 29.4 修复了这个问题:关闭 LevelDB 的 seek compaction,并定期压缩 chainstate(#35465)。
Bitcoin Core
chainstate 频繁写盘问题由 Bitcoin Core 30.3 解决。同时修复的还有 feebumper 在合并追加手续费不可用时崩溃(#34870),以及币选择中把金额算成布尔值的错误(#34888)。PSBT 方面,解析 pubnonce 和部分签名时现在会校验 MuSig2 公钥(#34219)。
Bitcoin Core
Bitcoin Core 31.1 堵上了 -privatebroadcast 的 IP 地址泄露:此前部分连接走了明网,没有经过已启用的隐私网络。造成磁盘活动过高的 chainstate 反复重写也到此为止,MuSig2 密钥聚合遇到空公钥列表时会直接拒绝(#35316)。
Bitcoin Core
v2 握手失败可能让 Bitcoin Core 31.0 用户的 IP 地址曝光:启用 -privatebroadcast 时,改用 v1 重试会跳过 Tor 代理,直连对等节点。最可能的触发方式是恶意节点故意中断握手。在 31.1 发布前,用户可以关闭该功能、设置 -v2transport=0,或让 IPv4/IPv6 出站流量全部走 Tor。
Bitcoin Core
0.14.0 之后、29.0 之前的 Bitcoin Core 版本在验证特制的无效区块时可能读取已释放的内存,导致节点崩溃。CVE-2024-52911 属高危,但攻击者必须在链尖投入有效工作量证明,发生远程代码执行的可能性也被认为不大。漏洞由 Cory Fields 报告,29.0 已包含修复。
Bitcoin Core
族群交易池(cluster mempool)在 Bitcoin Core 31.0 中取代旧设计:祖先和后代限制改为每个族群不超过 64 笔交易、101 kB,CPFP carveout 同时取消。内存不低于 4096 MiB 的机器,-dbcache 默认升至 1024 MiB;新增 -privatebroadcast 选项,让 sendrawtransaction 的广播只走 Tor 或 I2P。
Bitcoin Core
Bitcoin Core 28.4 修复了未命名钱包的两处故障:旧版钱包迁移失败(#34156),以及 createfromdump 失败时误删钱包目录(#34215)。chainparams 中还移除了一个 DNS 种子(#33723)。
Bitcoin Core
发送违反共识交易的对等节点,Bitcoin Core 29.3 不再惩罚(#33050)。验证环节为旧版、P2SH 和 segwit v0 脚本增加按输入缓存的 sighash 中间状态(#32473),识别见证剥离也无需重跑 Script 检查(#33105);矿工端 addPackageTxs 的无符号整数溢出已消除(#33475)。
Bitcoin Core
未命名旧版钱包迁移失败的问题随 Bitcoin Core 30.2 解决(#34156),createfromdump 处理这类钱包失败时也不会再删除钱包目录(#34215)。IPC wait 调用期间按 Ctrl-C 不再卡住(#33511)。
Bitcoin Core
极少数情况下,Bitcoin Core 30.0 或 30.1 迁移 wallet.dat 失败时可能删光钱包目录里的所有文件,危及资金。开发者已撤下这两版二进制文件,并要求用户在 30.2 推出前不要通过 GUI 或 RPC 迁移。触发条件是默认的未命名 wallet.dat 迁移或加载失败,其他用户不受影响。
Bitcoin Core
升级到 Bitcoin Core 30.1 后,钱包不再考虑带祖先交易的未确认 TRUC 币(#33528)。IPC 方面,选项不再强制要求 -m 参数(#33229),消息日志开销降低(#33517),正在运行的 waitNext 调用可以取消(#33676)。
Bitcoin Core
攻击者在多条连接中重复使用 version 消息的 nonce,伪造自连接,就能撑大 Bitcoin Core 节点的日志文件。受害节点的首条连接默认 60 秒超时,要填满磁盘得花很长时间,所以 CVE-2025-54604 只算低危。Niklas Goegge 于 2022 年报告此问题,29.1 和 30.0 引入的日志限速将其阻断。
Bitcoin Core
反复发送无效区块可能耗尽 Bitcoin Core 节点的磁盘:没有通过基本合理性检查、或在最后一个检查点之前分叉的区块,节点都会逐一记入日志。低危漏洞 CVE-2025-54605 由 Niklas Goegge 和 Eugene Siegel 分别独立报告,29.1 和 30.0 用日志限速解决。
Bitcoin Core
特制的非标准交易每笔可拖住 Bitcoin Core 节点数秒,发送者却不会被断开连接,攻击者得以借此延迟区块传播。低危漏洞 CVE-2025-46598 由 Antoine Poinsot 报告,v30.0 压缩了最坏情况下的验证时间,问题得到缓解。
Bitcoin Core
超过 1GB 的区块可能让 32 位 Bitcoin Core 节点的大小检查溢出,写入磁盘时崩溃,但区块必须以致密区块形式传来,受害者还得把 -maxmempool 设到 3GB 以上,交易池里存有 1GB 交易。Pieter Wuille 发现了这个低危漏洞(CVE-2025-46597);29.1 和 30.0 限制了 32 位系统的 -maxmempool,将其关闭。
Bitcoin Core
Bitcoin Core 28.3 下调默认最低费率:-blockmintxfee 降至每 kvB 1 聪,-minrelaytxfee 和 -incrementalrelayfee 降至每 kvB 100 聪。钱包费率不变;新默认值若未在全网普及,低费率交易可能传播不出去。白名单权限也不再适用于洋葱入站连接(#33395)。
Bitcoin Core