本周的 Newsletter 描述了 bip-anyprevout 软分叉提案，总结了 Magical Crypto Friends 会议上的一些技术演讲，并包含了我们关于 bech32 发送支持和值得注意的比特币基础设施项目变更的常规部分。

行动项

本周无。

新闻

• ● 提议的 anyprevout 签名哈希模式： 两周前，Anthony Towns 在 Bitcoin-Dev 和 Lightning-Dev 邮件列表上发布了一个提议的 BIP 供大家考虑。这个想法，bip-anyprevout，提供了两种新的签名哈希（sighash）模式，使签名能够对所花费资金的详细信息进行更少的承诺，而不是默认的 bip-taproot 和 bip-tapscript sighash 模式。这使得之前由 BIP118 描述的功能得以实现，并进行了一些修改，使其能够与 Taproot 一起工作，并降低误用的风险。其中一种新的 sighash 模式与 LN 的 Eltoo 层直接兼容，只需对 Taproot 进行修改并添加一个陪护签名（稍后描述）。另一种 sighash 模式比 Eltoo 所需的更多数据进行承诺，这可能使其在 Eltoo 中的非典型承诺或其他协议中有用。

  该提案相对于 BIP118 noinput 的一个显著优势是，它可以使用 Taproot 协作消费，允许 LN 通道或其他合同协议的两个或多个参与方在不透露任何合同条款（包括使用 anyprevout）的情况下选择性地花费他们的资金。

  为了快速了解 anyprevout，我们在基于 Eltoo 的两方 LN 通道的背景下考虑它。提醒一下，Eltoo 的关键特性是通道中的每次余额变更（状态更新）都可以由任何后续状态更新来花费，因此不像当前的基于惩罚的 LN 通道那样存在将旧状态发布到区块链上的风险。Eltoo 称这种能力为重新绑定，BIP118 提议通过允许签名跳过对支出交易输入部分的承诺来实现重新绑定——允许任何人修改交易的该部分，以绑定他们知道的任何后续状态。

  bip-anyprevout 定义的 SIGHASH_ANYPREVOUTANYSCRIPT 模式（任何先前输出，任何脚本）与 BIP118 noinput 类似，但有以下更改。要使用 anyprevoutanyscript，比较签名的公钥需要使用特殊前缀（0x00 或 0x01；不要与 bip-taproot 的输出密钥使用相同前缀混淆）。此外，正在评估的脚本需要至少包含一个不使用 anyprevoutanyscript 或稍后描述的其他新 sighash 模式的签名。这个非 anyprevout 签名称为陪护签名，因为在合理的假设下，它可以防止 anyprevout 签名被误用。（参见 Newsletter #34 了解关于重放问题的详细信息。）使用正确的前缀和陪护签名，anyprevoutanyscript 允许签名跳过对输出标识符（输出点）、先前输出的 scriptPubKey 和执行的 taproot 叶哈希（tapleaf）的承诺。签名承诺的交易摘要仍然包括有关前置输出的一些详细信息，例如其比特币值。

  此外，bip-anyprevout 还定义了另一种 sighash 模式：SIGHASH_ANYPREVOUT，它也需要相同的特殊公钥前缀和陪护签名，但它在签名中包含前置输出的 scriptPubKey 和 tapleaf 哈希。虽然 anyprevoutanyscript 允许 Eltoo 式重新绑定，其中任何后续状态可以绑定到任何早期状态（但早期状态不能绑定到后续状态），但在替代协议（以及 Eltoo 协议中的某些时间点）中，参与者可能希望确保状态 n 只能绑定到状态 n-1，而不是任何其他状态。

  该提案已经开始在邮件列表上接收反馈，因此我们将在后续的 Newsletter 中提供总结任何重要讨论的更新。

• ● Magical Crypto Friends 会议上的技术兴趣演讲： Bryan Bishop 提供了 MCF 会议上约十二场演讲和小组讨论的文字记录，会议组织者也上传了大部分视频。虽然这些演讲中只有一场描述了任何具体的新进展，但其中几场讨论了诸如保密交易、taproot、schnorr 和其他与比特币相关的技术的细节和影响。我们发现以下演讲特别有趣：

  • ● Andrew Poelstra 关于加密货币中使用的加密技术的演讲。特别是，他关注了构建系统的困难，这些系统中每个方面都需要正确完成才能抵御攻击。

  • ● Rodolfo Novak、Elaine Ou、Adam Back 和 Richard Myers 关于在没有直接访问互联网的情况下使用比特币的小组讨论。讨论主题包括基于卫星的区块传播、网状网络、业余无线电和物理传输数据（sneakernets），以及它们如何使比特币对于当前用户更加稳健，对于网络访问有限的地区用户更加可访问。我们发现关于比特币数据中继安全性的附带讨论特别有趣——简而言之，比特币协议已经设计为无信任地接受来自随机节点的数据，因此非网络中继不一定会改变信任模型。

  • ● Will O’Beirne、Lisa Neigut、Alex Bosworth 之间在 Leigh Cuen 主持下关于 LN 未来的对话，主要讨论了当前开发工作围绕 LN 1.1 规范的短期和中期结论。这个讨论中没有任何炒作的说法，只是简单描述了 LN 预计将如何改进，以使用户和企业更容易采用。

Bech32 发送支持

在 bech32 系列中，关于允许您支付的人访问 segwit 的所有好处的第 10 周。

到目前为止，在我们鼓励钱包和服务支持发送到 Bech32 原生 Segwit 地址的系列文章中，我们几乎完全专注于技术信息。今天，这部分内容表达了一个观点：你延迟实现 Bech32 发送支持的时间越长，一些用户和潜在用户对你的软件或服务的评价就会越差。

“他们只能支付到传统地址。”
“哦。那我们找一个支持当前技术的服务吧。”

仅支持传统地址的服务很可能会向用户传达出一个信号，即在维护其比特币集成方面付出的开发努力最少。我们预计，这会向用户传递出与2019年一个充满 Shockwave/Adobe Flash 元素并声称在 Internet Explorer 7 中最佳浏览的网站相同的信息（或参考 Gregory Maxwell 写的更具想象力的比较）。

Bech32 发送并不是一些仍需测试的实验性新技术——原生 Segwit 未花费输出目前持有超过 200,000 个比特币. Bech32 发送也是易于实现的（参见 Newsletter #38 和 #40）。最重要的是，随着越来越多的钱包和服务默认升级为 Bech32 接收，不提供发送支持的服务将显得落后。

如果你还没有实现 Bech32 发送支持，我们建议你在 2019 年 8 月 24 日之前尝试实现（Segwit 激活的两周年）。不久之后，Bitcoin Core 的下一个版本预计将在其 GUI 和可能的 API 方法中默认使用 Bech32 接收地址（参见 Newsletter #40 和 #42）。我们预计其他钱包也会这样做——除了那些已经默认 Bech32（甚至是唯一支持的地址格式）的钱包。

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

本周 Bitcoin Core、LND、C-Lightning、Eclair、libsecp256k1 和比特币改进提案（BIPs）中的值得注意的更改。

• ● Bitcoin Core #15006 扩展了 createwallet RPC，增加了一个新的 passphrase 参数，允许默认加密创建新钱包。现有钱包仍然可以通过 encryptwallet RPC 转换为加密。

• ● Bitcoin Core #15870 更改了 importwallet、importpubkey、importaddress 和 importprivkey RPC 与修剪的交互方式。之前如果启用了修剪，它们会失败。然而，修剪可以配置为手动操作（prune=1）或设置为大于当前区块链大小的值（例如 prune=450000），从而提供启用修剪但所有区块可能仍然存在的情况。通过此合并，只有当区块确实因修剪而丢失时，这些调用才会失败。或者，用户可以调用 importmulti RPC，只要数据的创建时间（时间戳）在尚未修剪的区块范围内，它将允许导入任何密钥或其他数据，即使区块已被修剪。

• ● Bitcoin Core #14802 通过使用 chainstate 撤销数据将 getblockstats RPC 的速度提高了 100 多倍（由 Optech 测量）——这是在区块链重组期间用于回滚分类账到以前状态的数据。这也消除了 RPC 对交易索引（txindex）的依赖。

• ● Bitcoin Core #14047 和 Bitcoin Core #15512 添加了加密 v2 传输协议所需的功能，描述见 Newsletter #39。这只是所需整体更改的一小部分；详情请参阅主要 PR #14032。

• ● C-Lightning #2631 扩展了 pylightning 实用程序，增加了三个新方法：autoclean 配置自动删除过期发票（默认在过期一天后删除）。check 确定命令是否有效而不运行它。setchannelfee 允许设置路由付款的费用，可以是添加到任何路由付款的基础费用，也可以是按付款金额比例应用的百分比费用。

• ● C-Lightning #2627 扩展了 pylightning，增加了 deleteinvoice 方法，删除指定时间之前过期的所有发票。