本周的 Newsletter 提到了交易费用估算的激增、描述了 LN 蹦床支付，并宣布 Bitcoin Core 计划在 0.20 版或更早版本中将其内置钱包的接收地址默认设置为 bech32。此外，还包括有关 bech32 发送支持和流行的 Bitcoin 基础设施项目中的值得注意的代码更改的常规部分。

行动项

  • ● 帮助测试 Bitcoin Core 0.18.0 RC2： 下一个 Bitcoin Core 主要版本的第二个候选版本（RC）已经发布。仍然需要计划在生产环境中运行新版本的 Bitcoin Core 的组织和有经验的用户进行测试。使用这个问题报告反馈。

网络状态

  • ● 快速确认的费用增加： 在过去一年多的时间里，大多数 Bitcoin 交易确认速度相当快，只要他们支付的费率高于默认最低中继费（除了在短暂的特殊时期），在过去的一周中，出现了一个适度的积压，导致需要在接下来的几个区块内确认其交易的人的费率提高。愿意等待更长时间的支出者仍然可以节省费用。例如，在撰写本文时，Bitcoin Core 的费用估算器建议每 1,000 vbytes 的 2 个区块内确认费用为 0.00059060 BTC，而 50 个区块内确认费用仅为 0.00002120——节省了超过 95% 的费用，最多等待额外 8 小时。有关更多信息，我们推荐 Johoe 的内存池统计数据和 P2SH.info 的费用估算跟踪。

新闻

  • ● LN 的蹦床支付： Pierre-Marie Padiou 在 Lightning-Dev 邮件列表中启动了一个线程，建议 Alice 可以通过首先向一个中间节点（Dan）发送支付并要求 Dan 找出到 Zed 的剩余路径来向 Zed 发送支付，即使她不知道到他节点的路径。这将特别有利于 Alice，如果她运行一个不试图跟踪整个网络的轻量级 LN 节点。为了增加隐私，Alice 可以使用多个中间节点而不仅仅是一个（每个节点收到 Alice 加密的自己的指令）。电子邮件中描述的一个缺点是，Alice 只能大致猜测所需的费用，因为她不知道实际路径，所以她可能最终支付的费用比她自己选择路线时要多。

  • ● Bitcoin Core 计划将默认接收地址切换到 bech32： 自 0.16.0 版本以来，Bitcoin Core 的内置钱包在用户希望接收支付时默认为生成 P2SH 包裹的 segwit 地址。这些地址与所有广泛使用的软件向后兼容。正如在问题和项目的每周会议中讨论的那样，从 Bitcoin Core 0.20 开始（预计约一年后），Bitcoin Core 将默认使用本机 segwit 地址（bech32），提供额外的费用节省和其他好处。目前，许多钱包和服务已经支持发送到 bech32 地址，如果 Bitcoin Core 项目在接下来的六个月中看到足够的额外采用，它将提前切换到 bech32 接收地址。在 GUI 或通过 RPC 请求时，P2SH 包裹的 segwit 地址将继续提供，如果用户不想要更新，也可以配置他们的默认地址类型。（同样，先锋用户现在可以在任何 Bitcoin Core 0.16.0 及以上版本中设置 addresstype=bech32 配置选项以更改其默认值。）

Bech32 发送支持

第 3 周，共 24 周。在 2019 年 8 月 24 日 segwit 软分叉锁定的二周年纪念日前，Optech Newsletter 将包含此每周部分，为开发人员和组织提供有关实现 bech32 发送支持（支付本机 segwit 地址的能力）的信息。这不需要实现 segwit本身，但确实允许你支付的人访问 segwit 的所有多个好处。

在前几周，我们讨论了创建传统地址输出与原生 segwit 地址输出之间的差异有多小。在那一部分中，我们简单地指引你参考 bech32 参考库并告诉你会得到两个值。本周，我们详细演示使用 Python 参考库的确切步骤，以便你可以看到工作量有多小。我们从导入库开始：

>>> import segwit_addr

Bech32 地址有一个可读部分 (HRP)，用于指示地址所属的网络。这些是地址的前几个字符，并由分隔符 1 与地址的数据部分分开。例如，比特币测试网使用 tb，一个示例测试网地址是 tb1q3w[…]g7a。我们将在代码中设置比特币主网的 HRP bc，以便我们可以确保解析的地址属于我们期望的网络。

>>> HRP='bc'

最后，我们有几个要检查的地址——一个应该有效，两个应该无效。（参见 BIP173 以获取完整的参考测试向量。）

>>> good_address='bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh'
>>> typo_address='bc1qd6h6vp99qwstk3z669md42q0zc44vpwkk824zh'
>>> wrong_network_address='tb1q3wrc5yq9c300jxlfeg7ae76tk9gsx044ucyg7a'

现在我们可以尝试解码每个地址

>>> segwit_addr.decode(HRP, good_address)
(0, [110, 175, 166, 4, 165, 3, 160, 187, 68, 90, 209,
     246, 218, 168, 15, 22, 43, 86, 5, 214])

>>> segwit_addr.decode(HRP, typo_address)
(None, None)

>>> segwit_addr.decode(HRP, wrong_network_address)
(None, None)

如果我们得到的第一个值（见证版本）是 None，则该地址在我们选择的网络上无效。如果发生这种情况，你需要在堆栈上抛出异常，以便与用户交互的过程可以让他们提供正确的地址。如果你得到一个数字和一个数组，则解码成功，校验和有效，长度在允许范围内。

见证版本必须是 0 到 16 之间的数字，因此你需要检查（例如 0 <= x <= 16），然后将其转换为相应的操作码 OP_0 到 OP_16。对于 OP_0，这是 0x00；对于 OP_1 到 OP_16，这是 0x51 到 0x60。然后你需要根据数据的长度添加一个推字节（2 到 40 字节为 0x02 到 0x28），然后将数据作为字节序列附加。Pieter Wuille 的代码很简洁地完成了这一点：

>>> witver, witprog = segwit_addr.decode(HRP, good_address)
>>> bytes([witver + 0x50 if witver else 0, len(witprog)] + witprog).hex()
'00146eafa604a503a0bb445ad1f6daa80f162b5605d6'

这就是你的完整 scriptPubKey。你可以在交易的输出中使用它并发送它。请注意，bech32 scriptPubKeys 的大小可以从 4 到 42 vbytes 不等，因此你需要在费用估算代码中考虑 scriptPubKey 的实际大小。

你的代码不需要用 Python 编写。参考库也提供了 C、C++、Go、Haskell、JavaScript、Ruby 和 Rust 的版本。此外，BIP173 对 bech32 的描述非常详细，以至于任何优秀的程序员都可以在他们首选的语言中从头实现它，而不需要超出大多数编程语言内置和标准库提供的功能。

其他 bech32 发送支持更新： BitGo 宣布他们的 API 现在支持发送到 bech32 地址；请参阅他们的公告以获取有关 bech32 接收支持的更多详细信息。Gemini 交易所本周也显然添加了 bech32 发送支持，并且用户报告称 Gemini 默认接受存款到 bech32 地址。

值得注意的代码和文档更改

本周在 Bitcoin Core、LND、C-Lightning、Eclair、libsecp256k1 和比特币改进提案（BIPs）中的值得注意的更改。注意：所有描述的 Bitcoin Core 合并都是在其主开发分支上；有些可能也会回移到 0.18 分支以便发布 0.18.0 版本。

  • ● Bitcoin Core #15620 停止 maxtxfee 配置参数影响 sendrawtransaction 和 testmempoolaccept RPC。之前这些 RPC 会默认拒绝支付费用高于配置最大值的交易。现在使用硬编码的默认值 0.1 BTC 作为可接受的上限。maxtxfee 配置参数仍由 Bitcoin Core 的内置钱包使用；它只是与节点特定的 RPC 分开使用。此更改是钱包配置选项清理的一部分，也是节点和钱包分离的一部分（两者在此更改之前都使用该设置）。

  • ● Bitcoin Core #15643 更改了 Bitcoin Core 开发人员用于合并提交的 Python 脚本，以便 git 合并消息中包含批准（ACKed）合并版本的开发人员列表。（这个内部项目更改本身可能并不值得注意，但该工具的另一个功能——将完整的 PR 描述复制到合并消息中——使得本节作者编写这些合并摘要变得更加容易，因此他鼓励其他 Bitcoin 项目调查使用此工具的优势，以自动创建更好的基于 git 的文档，以及提高他们的安全性和可审核性。）

  • ● Bitcoin Core #15519 添加了 Poly1305 实现到 Bitcoin Core，但没有使用它。预计稍后将用于实现P2P 协议加密。

  • ● Bitcoin Core #15637 修改了与内存池相关的 RPC（例如 getrawmempool）以将 size 字段重命名为 vsize。以前的值也是 vsize，因此计算没有变化。此合并的 PR 只是明确这是一个 vsize 而不是一个剥离的大小。为了向后兼容，可以使用 deprecatedrpc=size 参数启动 Bitcoin Core 以继续使用旧字段名称，尽管这将在未来版本中删除。

  • ● LND #2759 降低了所有通道的默认 CLTV delta 从 144 个区块（大约 24.0 小时）到 40 个区块（大约 6.7 小时）。当 Alice 想通过一系列路由节点支付给 Zed 时，她首先将资金给 Bob，条件是要么 Alice 可以在（例如）400 个区块后收回资金，要么 Bob 可以在此之前提供一个特定哈希的前映像（打开哈希锁的密钥）来领取资金。400 个区块的延迟在链上使用 OP_CHECKLOCKTIMEVERIFY（CLTV）进行强制执行。然后，Bob 以类似的条件将资金（减去他的路由费）发送给 Charlie，只是 CLTV 值从 Alice 的原始 400 个区块减少了他与 Charlie 的通道的 CLTV delta，减少到 360 个区块。这确保了如果 Charlie 等待最长时间（360 个区块）来完成他的 HTLC 并领取他的付款，Bob 仍有 40 个区块来完成原始 HTLC 并从 Alice 那里领取他的付款。如果 Bob 与 Charlie 的 HTLC 到期时间没有减少，使用 400 个区块的延迟，Bob 将面临损失资金的风险。Charlie 可以延迟完成他的 HTLC 到 400 个区块，然后 Alice 可以在 Bob 有时间完成 HTLC 之前取消她与 Bob 的 HTLC。

    随后的路由器分别从他们给下一个节点的条款值中减去他们的 delta。因此，使用高 CLTV delta 会减少可以在路由中使用的跳数，并使通道在路由支付时不太具有吸引力。

  • ● Eclair #894 用 HTTP POST 接口替换 JSON-RPC 接口。使用 HTTP 端点而不是 RPC 命令（例如 channelstats RPC 现在是 POST http://localhost:8080/channelstats）。参数使用与 RPC 参数相同的 JSON 语法作为命名的表单参数提供。返回的结果与更改前相同。旧接口仍可使用配置参数 eclair.api.use-old-api=true 使用，但预计将在后续版本中删除。有关详细信息，请参见更新的 API 文档。