本周的 Newsletter 链接到了一次关于使用增强版 QR 码来传递大额交易的讨论，包含了 Suredbits 提供的关于构建高可用性闪电网络节点的现场报告，并简要总结了几场最近转录的演讲和对话。此外，还包含了我们常规的发布、候选发布以及流行的比特币基础设施软件中值得注意的代码更改部分。

行动项

Happy halving!

新闻

  • ● 大额交易的 QR 码： QR 码的实际容量上限约为 3 KB，这足以容纳典型的用户交易，但远不足以容纳用户通常可以发送的最大交易。Riccardo Casatta 和 Christopher Allen 分别在 Bitcoin-Dev 邮件列表中发帖（1，2），请求讨论以期望规范化一种方法，用于以视觉方式传递部分签名比特币交易（PSBTs）以及其他潜在的大型数据块，涉及比特币钱包的交互。请参见 Specter DIY 仓库中的先前讨论，并在 Airgapped Signing 仓库中继续讨论。

实地报告：在企业环境中运行闪电网络节点

作者：Roman Taranchenko，Suredbits 工程师

在第一次使用闪电网络发送支付，尤其是成功接收支付的兴奋过后，如何以安全可靠的方式操作你的节点是一个需要思考的问题。故障几乎总是出乎意料地发生。遇到可能的故障后如何恢复？如何让备份更加可靠？如何将种子保存在一个安全的地方？等等，等等……

在 Suredbits，我们使用 Eclair 作为我们的节点软件。尽管 Eclair 本身已经相当稳健，我们仍采取了一些措施以进一步提高其可靠性——例如使用 PostgreSQL 作为数据库后端（通过此 PR），并使用 AWS Secrets Manager 来存储私钥。

Eclair 内置了在线备份功能，但它需要手动设置和编写脚本来实现自动化，这在大规模操作中并不适用，而且容易出错。使用 AWS RDS 运行 PostgreSQL 使我们能够以一种 DevOps 工程师熟悉的方式来自动化备份和复制，并简化了数据库状态的恢复。

将 PostgreSQL 作为远程数据库后端使得实现节点故障切换更加简单，因为如果节点由于某种原因崩溃，就无需从备份中恢复数据库——你所需要做的只是将一个新的 Eclair 实例指向正确的数据库服务器。以下是一个使用两个 Eclair 实例加上 AWS 的 RDS、ELB 和 NAT Gateway 实现的自动故障切换的快速演示。

在演示中所描述的故障切换场景中，我们需要一种安全的方式来允许 Eclair 实例之间共享其私钥种子。Eclair 将种子存储在本地文件系统中的一个文件里，这个文件应该被备份到某个地方，并在需要时恢复。目前的 Eclair 实现需要额外的步骤才能实现自动化。我们使用 AWS Secrets Manager——一个专门设计用于安全存储各种秘密信息（包括数据库密码和加密密钥）的加密键值存储。现在，只需在配置文件中将实例指向正确的密钥位置即可共享种子。一旦配置完成，实例就可以存储为 AMI 镜像，可以在无需手动配置的情况下根据需要多次重建。

我们采取的这些措施只是构建企业级闪电网络节点的第一步。仍然有一些问题需要解决。例如，哪些硬件安全模块（HSM）可以用于闪电网络节点，或者如何在多实例环境中实现 Bitcoin Core 节点的故障切换。但我们相信，我们的工作为扩展 Eclair 并使其更加容错奠定了坚实的基础。

有关此主题的更多信息，请参见我们的演讲。

免责声明：由于涉及私钥，在未进行彻底的风险评估前，请勿使用第三方云服务。

最近转录的演讲和对话

Bitcoin Transcripts 是一个收录比特币技术演讲和讨论的转录库。在这个新的 每月特辑中，我们重点介绍了上个月的部分转录内容。

  • ● Simplicity—下一代智能合约 Adam Back 在 Blockstream 的一个网络研讨会上介绍了 Simplicity，这是一种下一代的低级比特币脚本替代方案，专注于可证明的安全性和表达能力。Back 讨论了如果今天在比特币中启用 Simplicity，开发者可以如何实现诸如 SIGHASH_NOINPUT 之类的新功能，而不必进行软分叉。他还展示了一个演示，展示了当前使用 Simplicity 可以实现的功能。（转录，视频，幻灯片）

  • ● 攻击 Bitcoin Core Amiti Uttarwar 在 LA BitDevs 上发表了演讲。Uttarwar 讨论了如何根据五个目标来评估对比特币对等层的更改：可靠性、及时性、可访问性、隐私性和可升级性。她讨论了网络分区和 eclipse 攻击的危险性，并解释了为什么仅限区块中继的连接和锚节点是有效的缓解措施。（转录，视频）

  • ● LND v0.10 Laolu Osuntokun、Joost Jager 和 Oliver Gugger 在 Reckless VR 上进行了虚拟现实演讲。Osuntokun 介绍了 LND 最新版本中的 Tor 和 RPC 增强功能，以及一种新的通道功能锚输出，该功能解决了提前数月估算链上费用的挑战。Jager 讨论了多路径支付的挑战，包括拆分算法、当支付的分片在不同时间到达时的处理，以及处理多路径支付失败的策略。Gugger 最后讨论了使用部分签名比特币交易（PSBT）进行通道资金筹集以及使其成为可能的通道抽象化工作。（转录，视频）

  • ● 掌握比特币 Kalle Rosenbaum 参加了一次比特币开发者见面会，并在 London Bitcoin Devs 上发表了演讲。见面会的讨论重点是比特币技术教育的作用、BIP32 HD 钱包和软分叉升级。在演讲中，Rosenbaum 使用其书中的内容讨论了 2017 年的 SegWit 升级如何解决了交易延展性和二次哈希的问题。（见面会转录，演讲转录，演讲视频，演讲幻灯片）

发布与候选发布

流行的比特币基础设施项目的新版本发布与候选发布。请考虑升级到新版本或帮助测试候选发布。

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

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

注意：以下提到的 Bitcoin Core 提交适用于其主开发分支，因此这些更改可能要到 0.21 版本才会发布，约在即将发布的 0.20 版本之后六个月。

  • ● Bitcoin Core #16528 允许 createwallet RPC 创建一个使用输出脚本描述符来推导钱包用于接收支付的特定 scriptPubKey 的钱包。这比旧钱包扫描所有类型脚本的方式有了重大改进，旧钱包需要为每个公钥推导钱包处理的每种脚本类型——这一技术可以追溯到最初的 Bitcoin 0.1 版本支持接收 P2PK 和 P2PKH scriptPubKey。描述符钱包应该更高效（因为它们不需要扫描未使用的脚本类型）、更容易升级到新类型的脚本（例如 taproot），并且更容易与外部工具一起使用（例如通过部分签名比特币交易支持的多重签名钱包或 HWI 兼容的硬件钱包）。

    默认情况下，描述符钱包使用 BIPs 44、49 和 84 指定的流行 BIP32 HD 钱包路径，而不是旧 Bitcoin Core HD 钱包中使用的非标准的全加密路径。由于描述符的一些特性或开发人员仍在适应新的边缘情况，某些钱包 RPC 无法与描述符钱包一起使用。该 PR 在 0.21 开发周期的早期合并，并决定将描述符钱包设为非默认选项，这将使新功能在预期发布前有六个月的成熟时间。

  • ● Bitcoin Core #18038 通过减少钱包尝试重新发送交易的频率（从大约 30 分钟到大约一天一次）来提高最初广播交易的隐私性。以前，监控网络的实体可能会在这些重新发送期间看到同一交易的多次广播，并得出钱包是发起者的结论。通过减少钱包重新发送尝试的频率，交易的发起者被识别的机会更少。

    为确保新交易即使在没有钱包频繁不加选择的重新广播的情况下也能到达网络，此 PR 还增加了一种在内存池中 未广播 的交易。未广播的交易是通过钱包或 RPC 本地提交但尚未成功中继到网络节点的交易。这些未广播的交易将保留在内存池中，并每 10-15 分钟重新广播一次，直到某个节点通过发送 getdata P2P 消息来获取该交易。

  • ● BIPs #893 对 BIP340 规范的 schnorr 公钥和签名进行了多项更改，并对 BIP341 的 taproot 规范进行了相关更改。主要更改包括：

    • ● x-only 公钥的替代决策规则： 这改变了当仅知道公钥的 x 坐标时使用的公钥变体，如之前讨论的那样（参见 Newsletter #83）。

    • ● 更新的随机数生成建议： 建议用于生成签名随机数的方法已更新，以防止特定实现的漏洞（参见 Newsletter #83 和 #91 的先前讨论）。

    • ● 更新的标记哈希： 为 schnorr 签名前缀到哈希函数输入的标签已更新，以故意破坏与旧草案规范的兼容性。否则，为旧代码编写的库可能有时会生成在新代码下有效的签名，有时又不会，从而导致混淆。这也在 Newsletter #83 中提到。

  • ● BIPs #903 简化了 BIP322 规范的通用签名消息，如先前提议的那样（参见 Newsletter #91），此更改主要是删除允许在同一证明中为多个脚本（地址）签名的详细信息。

  • ● BIPs #900 更新了 BIP325 规范的 signet，使所有 signet 使用相同的硬编码创世区块（区块 0），但独立的 signet 可以通过其网络魔法值（消息开始字节）区分。根据更新后的协议，消息开始字节是网络的挑战脚本（用于确定区块是否具有有效签名的脚本）哈希摘要的前四个字节。更改的动机是简化希望使用多个 signet 的应用程序的开发，这些应用程序需要调用硬编码支持网络创世区块的库。