本周的 Newsletter 描述了希望替代 BIP70 支付协议部分功能的相关讨论，并总结了为 Discreet Log Contracts（DLCs）交换欺诈证明进行标准化的方法提议。还包括我们定期的部分，介绍新的软件发布、可用的候选发布以及对流行比特币基础设施软件中值得注意的更改。

新闻

• ● 关于 BIP70 替代方案的讨论： Thomas Voegtlin 在 Bitcoin-Dev 邮件列表上发起了一个话题，讨论对 BIP70 支付协议部分功能（特别是接收已签名支付请求的能力）进行替代的方案。Voegtlin 希望能够证明他支付的地址确实是由收款方（例如交易所）提供的地址。Charles Hill 和 Andrew Kozlik 分别回复了他们正在研究的协议。Hill 的方案旨在与 LNURL 一起使用，但可以重新用于 Voegtlin 的预期用例。Kozlik 的方案在精神上更接近 BIP70，但不再使用 X.509 证书，并为基于交易所的币种互换（例如 BTC 与其他币种的互换）添加了新特性。

• ● v0 版 Discreet Log Contract (DLC) 规范中的欺诈证明： Thibaut Le Guilly 在 DLC-dev 邮件列表上发起讨论，讨论在 DLCv0 欺诈证明目标中包含欺诈证明。讨论了两种类型的欺诈：

  • ● 多重证明（equivocation）： 当预言机（oracle）为同一事件多次签名，从而产生相互冲突的结果。多重证明可由软件自动验证，无需第三方信任。

  • ● 撒谎（lying）： 当预言机为用户明知错误的结果签名。这几乎总是依赖于用户合约软件无法获取的证据，因此这种欺诈证明必须由用户手动验证，用户需要将原始合约与预言机签名的结果进行比较。

  参与讨论的人员似乎都倾向于提供多重证明，但有人担心这对 v0 规范来说工作量太大。作为中间解决方案，有人建议先专注于撒谎证明。当这些证明的格式确定后，软件就可以针对同一预言机和事件使用两份独立证明来构建多重证明。

  关于撒谎证明的一个担忧是，用户可能会被假证明垃圾信息轰炸，迫使用户要么浪费时间验证假的欺诈证明，要么完全放弃检查欺诈证明。反对意见包括可以从链上交易中获取证明的一部分（这需要有人支付链上费用），以及用户可以选择他们从哪里下载欺诈证明，倾向于从以传播准确信息而闻名的来源获取。

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

本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs） 中的值得注意的更改。

• ● Bitcoin Core #16546 引入了一个新的签名器接口，允许 Bitcoin Core 通过 HWI 或实现相同接口的其他应用与外部硬件签名设备交互。

  自 Bitcoin Core 0.18 版本起，Bitcoin Core 就能够使用 HWI 连接硬件签名器（参考 HWI 发行版）。然而在此 PR 之前，该过程需要使用命令行在 Bitcoin Core 和 HWI 之间传输数据。该 PR 简化了用户体验，使 Bitcoin Core 可以直接与 HWI 通信。此 PR 包含了完整文档，说明如何结合 HWI 使用新的签名器接口。

  新的签名器接口目前仅可通过 RPC 方法访问。一个草案 PR 为 GUI 添加了对签名器接口的支持，从而无需使用命令行就可在 Bitcoin Core 中使用硬件签名器。

• ● Rust-Lightning #791 在启动时增加了对轮询 BlockSource 接口以同步区块和区块头的支持，并在同步中检测分叉。正如在 Newsletter #135 中所述，BlockSource 允许软件从非标准 Bitcoin Core 节点的数据源获取数据，从而在冗余层面帮助防止日蚀攻击（eclipse attacks）或其他安全问题。

• ● Rust-Lightning #794 为 BOLT2 的 option_shutdown_anysegwit 特性提供支持，该特性在关闭时允许使用未来的 segwit 版本。如果协商了 option_shutdown_anysegwit，则通道一方在发送关闭消息以启动关闭时，可发送一个支付用的 scriptpubkey，只要该脚本符合标准的 BIP141 见证程序格式：一个版本字节（OP_1 到 OP_16 的 1 字节 push 指令）后跟一个见证程序字节向量（长度为 2 到 40 字节的推送）。这些关闭脚本限制为标准格式，以避免由于非标准而无法传播的高费用复杂脚本或超大脚本的交易。由于在 Bitcoin Core 0.19.0.1（2019 年 11 月发布）可以为任何 segwit 脚本转发支付，现在在 LN 的标准格式中安全包含它们。

• ● HWI #413、#469、#463、#464、#471、#468 和 #466 显著更新并扩展了 HWI 的文档。特别值得注意的变化包括在 ReadTheDocs.io 上提供的文档链接、新的和更新的示例，以及描述 HWI 考虑支持新设备标准的政策。

• ● Rust Bitcoin #573 增加了一个新的方法 SigHashType::from_u32_standard，确保所提供的 sighash 字节是 Bitcoin Core 默认中继和打包的标准值之一。每个签名的 sighash 字节指示需要签名的交易部分。比特币的共识规则规定非标准 sighash 值被视为等同于 SIGHASH_ALL，但由于默认情况下不中继或打包非标准值，理论上可以用来欺骗使用链下承诺的软件，从而接受不可强制执行的支付。使用 Rust Bitcoin 的开发者可能希望从接受任意共识有效 sighash 字节的 SigHashType::from_u32 方法转为使用此新方法。

• ● BIPs #1069 更新了 BIP8，允许配置激活阈值，并基于最近的 taproot 激活讨论将推荐值从 95% 降至 90%。