/ home / newsletters /
Bitcoin Optech Newsletter #142
本周的 Newsletter 描述了一篇关于在闪电网络中进行概率路径选择的论文及简短讨论，并包含我们的常设栏目：Bitcoin Stack Exchange 精选问答、新版本和候选发布，以及对比特币基础设施软件值得注意的更改。
行动项
新闻
-
● 关于概率路径选择的论文： René Pickhardt 在 Lightning-Dev 邮件列表中发布了一篇由他与 Sergei Tikhomirov、Alex Biryukov、Mariusz Nowostawski 共同撰写的论文。该论文对拥有统一分布余额（在各自通道容量范围内）的网络通道进行建模。例如，对于 Alice 和 Bob 之间容量为 1 亿聪的通道，论文假定该通道可能处于下表中所有状态的概率相同，并假设网络中的每个其他通道也是如此：
Alice Bob 0 sat 100,000,000 sat 1 sat 99,999,999 sat … … 100,000,000 sat 0 sat 基于这一假设，作者得出关于支付成功概率的结论，这些结论与支付金额及其需要经过的跳数（通道数）相关。这些结论支持若干已知的启发式方法的优点——例如保持路径短以及使用 multipath payments（多路径支付） 将大额支付拆分为小额支付（在特定其他假设下）。他们还使用该模型评估新提议，如允许通过 bolts #780 的 Just-In-Time (JIT) rebalancing（及时再平衡）。
该论文利用其结论提供了一种路由算法，据称可在与他们简化的现有路由算法相比下减少 20% 的支付重试次数。新算法偏好具有较高计算成功概率的路由，而现有算法则采用启发式方法。如果结合 JIT 再平衡，他们估计可获得 48% 的改进。鉴于每次重试通常需要数秒，有时更长，这可能显著改善用户体验。该算法在多个示例网络中进行了测试，包括从近 1000 个真实存在的通道中获取快照的网络。
该论文有意不考虑路由费用，多数邮件列表中的回应集中于如何在不让用户支付过高费用的前提下利用这些研究结果。
-
● 更新后的支付批处理文章： Optech 已发布一篇关于支付批处理的文章，相较于我们在 Newsletter #37 中的最初公告进行了更新。支付批处理是一种技术，可帮助支付方节省多达 80% 的交易手续费。
Bitcoin Stack Exchange 精选问答
Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选之地之一——或在我们有空时帮助好奇或困惑的用户。在本月特刊中，我们会重点展示自上次更新以来获得高票的问题和解答。
-
● 交易所采用原生 Segwit 有多难？ 比特币开发者 instagibbs 列出交易所实施原生 Segwit 时需考虑的几点，包括地址生成、确保可花费性、支持与商业考虑以及硬件安全模块（HSM）等签名基础设施的兼容性。
-
● 如何计算 98% 的比特币何时被挖出？ Murch 提供了一个估测，大约在 2030-2031 年达到 98% 的比特币已被挖出，并附上 奖励时间表的 Google 表格 以参考更多指标。
-
● 如何在 Bitcoin Core 中使用匿名网络协议 I2P？ 随着 Bitcoin Core #20685 的合并，比特币支持 I2P 网络。Michael Folkson 总结了 Jon Atack 的原始讨论主题，介绍了如何配置 Bitcoin Core 使用 I2P。
-
● 具有大于默认内存池的节点会重传那些从较小内存池中已丢弃的交易吗？ Pieter Wuille 指出当前的交易重广播由钱包负责，也许节点也应重广播未确认交易，并指向 Bitcoin Core #21061 这一进展中的目标。
-
● 软分叉激活机制应使用区块高度还是 MTP（中位时间过去值），或两者混合？ David A. Harding 概述了 MTP 与区块高度这两种计时机制的优缺点。MTP 大致对应实时时间，但矿工可操纵以跳过某个信号区间。区块高度不一致，但也不像 MTP 那样能被矿工轻易操控。
-
● 为何为提高隐私性而建议在支付时不要使用整数数额？ 用户 chytrik 提供了不同示例说明整数金额启发式及为何避免整数支付金额有助于提高隐私性。
发布与候选发布
流行的比特币基础设施项目的新版本和候选发布。请考虑升级到新版本或协助测试候选发布。
-
● BTCPay Server 1.0.7.1 修复了若干安全漏洞，同时包含诸多改进和非安全性错误修复。
-
● HWI 2.0.1 是一个修正版本，解决了 Trezor T 输入密码和
hwi-qt用户界面键盘快捷键的轻微问题。 -
● C-Lightning 0.10.0-rc2 是该闪电网络节点软件下一个主版本的候选发布。
值得注意的代码和文档更改
本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs）中值得注意的更改。
-
● Bitcoin Core #17227 为构建系统添加了新的
make apk目标，用于为 Android 操作系统打包 bitcoin-qt。这延续了此前的工作，即为打包 Android NDK 提供支持。该合并还包括构建 Bitcoin Core 的 Android 文档以及一个持续集成任务用于测试 Android 构建系统。 -
● Rust-Lightning #849 使通道的
cltv_expiry_delta可配置，并将默认值从 72 个区块降低至 36 个区块。该参数设定了在节点从下游节点获知支付成功与否后，需在与上游节点完成支付尝试结算的截止时间。它必须足够长以在必要时上链确认，但又要足够短以在与尝试最小化延迟的其他节点竞争中保持竞争力。另见 Newsletter #40，当时 LND 将其值降至 40 个区块。 -
● C-Lightning #4427 通过使用
--experimental-dual-fund配置选项，使得可实验双向资助的支付通道成为可能。双向资助允许初始通道余额由发起通道的节点和接受通道的节点共同出资，这对希望在通道完成开启后立即开始接收付款的商户和其他用户很有用。 -
● Eclair #1738 在使用锚定输出时更新了针对撤销 HTLC 所实施的惩罚机制。当在协议中添加 anchor outputs 时引入的一项与其无关的变更，使得可将多个
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY的 HTLC 输出合并为单笔交易（参见 Newsletter #128）。此拉取请求确保所有可由撤销密钥花费的输出在同一笔交易中申领，而不是每笔交易仅申领一个输出。 -
● BIPs #1080 使用
minimum_activation_height参数更新了 BIP8，该参数在锁定软分叉后延迟节点开始执行该软分叉规则的时间，直到达到指定的高度。这使 BIP8 与 Speedy Trial 提案（参见 Newsletter #139）兼容，该提案允许矿工激活 taproot，但在大约六个月后才开始强制执行 taproot 规则，这通常是在实现 Speedy Trial 的软件发布之后。