/ home / newsletters /
Bitcoin Optech Newsletter #359
本周的新闻部分介绍了一个在 Bitcoin Core 代码库中限制公开参与的提议、宣布了一个对 BitVM 式合约的重大改进,并总结了对闪电通道再平衡的研究。此外是我们的常规栏目:客户端和服务端软件近期的变更总结、软件新版本和候选版本的公告、热门的比特币基础设施软件的近期变更介绍。
新闻
-
● 限制对 Bitcoin Core 项目访问的提议和讨论:Bryan Bishop 在 Bitcoin-Dev 邮件组中发帖建议 Bitcoin Core 项目限制公众参与项目讨论的能力,以减少由非贡献者带来的干扰。他称之为 “私密化 Bitcoin Core”,并指出了这种私密化已经作为一种权宜之计、在多位 Bitcoin Core 贡献者的私人办公室中发生的例子,并警告说,面对面的私密化会疏远远程贡献者。
Bishop 的帖子提出了一种线上私密化的方法,但 Antoine Poinsot 质疑这种办法能否实现目标。Poinsot 还指出,许多私人办公室讨论之所以发生,可能并不是因为对公开批评的畏惧,而是因为 “面对面讨论的天然优势”。
多个回复都指出,此时作出重大变更可能是不合理的,但对库中的评论作出更强力的调节也许能缓解破坏力最大的干扰类型。不过,其它回复也指出了更强力调节将面临的一些挑战。
Poinsot、Sebastian “The Charlatan” Kung 和 Russell Yanofsky —— 截至本刊撰写之时,回复此帖的人中仅有的几位高度活跃的 Bitcoin Core 贡献者 —— 表示要么不认为重大变更是必要的,要么任何变更都应该渐进施行。
-
● BitVM 式合约的重大提升:Robin Linus 在 Delving Bitcoin 中宣布, BitVM 式合约在所要求的链上空间数量上取得重大削减。基于 Jeremy Rubin 的一个想法、开发出新的密码学原语后,新方法 “相比于原有的设计,将争议解决的链上开销降低了超过 1000 倍”,反证交易 “只有 200 字节大小”。
不过,Linus 的论文也指出了这一方法的取舍:它 “的启动设置需要几 TB 的链下数据”。论文给出了一个 SNARK 验证器电路的例子,由 500 万个逻辑门组成,而合理的安全参数需要 5 TB 的链下数据;见证结果需要 56 kB 的链上交易,在一方需要证明这样的结果无效的情形中,只需要提交极小的链上交易(约 200 B)。
-
● 通道再平衡研究:Rene Pickhardt 在 Delving Bitcoin 论坛中发布了关于再平衡通道来最大化整个网络的支付成功率的想法。他的想法可以跟关注更小的通道集群的想法(比如 “朋友的朋友再平衡”,详见 周报 #54)相比较。
Pickhardt 指出全局方法面临许多挑战,并请求感兴趣的参与者回答几个问题,比如这个方法是否值得追求、如何解决特定的实现细节。
服务端和客户端软件的变更
在这个月度栏目中,我们会列出比特币钱包和服务的有趣更新。
-
● Liana v11.0 发布:Liana 的最新版本加入了多钱包特性、钱币控制特性以及对更多硬件签名器的支持;此外还新增了别的特性。
-
● Stratum v2 STARK 证明演示:StarkWare 演示了一个修改后的 Stratum v2 挖矿客户端,使用一个 SATRK 证据来证明属于一个有效的区块模板的手续费,而不必揭开这个区块中的交易。
-
● Breez SDK 加入了 BOLT12 和 BIP353:Breez SDK Nodeless 0.9.0 添加了使用 BOLT12 和 BIP353 来收款的特性。
新版本和候选版本
热门的比特币基础设施项目的新版本和候选版本。请考虑升级到新版本或帮助测试候选版本。
- ● Core Lightning 25.05 是这个热门的闪电节点实现的下一个主要版本的候选发行。该版本降低了转发和解析支付的时延、增强了手续费管理、提供了跟 Eclair 兼容的 “通道拼接” 特性,并默认启用对等节点存储协议。注意:其发行说明书包含了一个对使用
--experimental-splicing
配置选项的用户的警告。
显著的代码和说明书变更
本周出现重大变更的有:Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals (BIPs)、Lightning BOLTs、Lightning BLIPs、Bitcoin Inquisition 和 BINANAs。
-
● Eclair #3110 将标记一条通道为关闭的时延从其注资输出被花费之后的 12 个区块(详见周报 #337)提高到 72 个区块,如 BOLTs #1270 所指定的,以允许拼接更新的传播。提高这一数值,是因为一些实现在发送
splice_locked
之前默认要等待 8 个区块,而且允许节点运营者提高这个门槛,所以 12 个区块已经被证明是太短了。当前,这一数值在测试用途中是可以配置的,以允许节点运营者等待更长时间。 -
● Eclair #3101 引入了
parseoffer
PRC,它会解码 BOLT12 offer 为明文可读的格式,从而用户可以在将 offer 传递给payoffer
PRC 之前看到支付的数额。后者已经扩展成接受以法币单位指定的数额。 -
● LDK #3817 撤回了对 “可归因故障”(详见周报 #349)的支持,仅在 test-only 的启动标签下才可使用。这禁用了对等节点的惩罚逻辑,并从传递故障的洋葱消息中移除了特性 TLV。尚未升级的节点被错误地惩罚了,表明更广泛的网络采用是这种技术正常工作的前提。
-
● LDK #3623 拓展了对等节点存储协议(详见周报 #342)以提供自动化的、加密的对等节点备份。每过一个区块,
ChainMonitor
都会将来自一个带有版本、时间戳且被序列化的ChannelMonitor
结构体的数据打包成一个OurPeerStorage
包裹。然后,它会加密这个数据,并唤起一个SendPeerStorage
事件、将这个包裹作为一条peer_storage
消息转发给每一条通道的对等节点。此外,ChannelManager
更新为通过触发一次新的包裹发送来处理peer_storage_retrieval
请求。 -
● BTCPay Server #6755 强化了钱币控制的用户界面:添加了新的最小数额和最大数额过滤器、创建 早于/晚于 某日期过滤器、这些过滤器的帮助选项、UTXO “全选” 选择框,以及页面大小选择(100 条、200 条或 500 条 UTXO)。
-
● Rust libsecp256k1 #798 在库中完成了 MuSig2 实现,为下游项目给出了使用一种健壮的无脚本多签名协议的方法。