比特币操作码技术新闻通讯190期
翻译：Google Translate 校对：李林
本周的时事通讯描述了关于未来软分叉应该在多大程度上增加比特币脚本和 Tapscript 语言的表达能力的讨论的多个方面，并总结了一项对用于中继洋葱消息的带宽收费的提议。 还包括我们的常规部分，其中包括比特币核心公关审查俱乐部会议的摘要、新软件版本和 RC 的公告，以及对流行的比特币基础设施项目的显着变化的描述。
新闻
● 限制脚本语言的表达能力：在 Bitcoin-Dev 邮件列表中，针对将 OP_TXHASH 或 OP_TX 操作码添加到 Script 的提议开始了几个子讨论（参见 Newsletters #185 和 #187)。 Jeremy Rubin 注意到 提案（可能与其他操作码提案相结合，例如 OP_CAT) 可能允许创建递归 covenants——需要的条件在每笔交易中重新使用这些比特币或与之合并的任何比特币，以实现永续性。有人询问 是否有人担心允许比特币中的递归契约，总结了一些最值得注意的问题以下：
● 抗审查能力逐渐消失：贡献者 Shinobi 已发布 重复了他之前在时事通讯中提到的担忧 #157关于递归契约，该契约赋予强大的第三方控制该实体当前控制的任何代币的后续支出。例如，政府可以（通过法律）要求其民众只接受政府以后可以没收的硬币（由比特币共识规则强制执行）。
回复 对 Shinobi 的帖子回应 一年前 的论点也认为抗审查能力逐渐消失也存在于其他地方，如通过用户切换到对第三方控制具有相同要求的替代加密货币（山寨币）或类似侧链的结构。
● 鼓励不必要的计算：开发者 James O’Beirne 表示 担心比特币脚本增加了太多的表现力或Tapscript 语言将鼓励创建脚本，这些脚本使用的操作次数超过了证明授权花费硬币的人选择花费这笔钱所需的最少操作次数.理想情况下，任何 UTXO（硬币）今天都可以使用单一的紧凑证明来证明支出已获得授权，例如 64 字节 schnorr 签名 .比特币已经允许更复杂的脚本来创建合约，例如多重签名契约和像 LN 这样的协议，但是这种能力可以被滥用以在脚本中包含执行合约条款所不需要的操作。例如，比特币过去一直处于风险 来自重复执行的特殊设计交易的拒绝服务攻击需要大量 CPU 或内存的操作。 O’Beirne 担心表达能力的提高既会创建新的 DoS 向量，也会导致程序员创建未优化的脚本，这些脚本使用了不必要的节点资源。
● 引入图灵完整性：开发人员 ZmnSCPxj 批评 添加了允许创建故意递归约定的操作码，同时也允许意外创建递归约定。支付给递归契约的钱，无论是有意还是无意，都不会再与普通比特币完全可替代。ZmnSCPxj在图灵完整性和停机问题的背景下表达了这种担忧。
● 驱动链的启用：扩展他之前关于图灵完整性的论点，ZmnSCPxj 进一步认为增加脚本语言的表达能力也会启用 drivechains 的实施，原则上与 BIP300 中指定的类似，几位比特币开发人员争论 可能导致用户资金损失或减少抗审查能力。如果没有足够的比特币经济体选择运行完整的节点来执行驱动链的规则，那么驱动链的用户可能会损失资金——但如果大部分经济体确实选择执行驱动链的规则，那么所有其他想要保持共识的用户都需要验证所有驱动链的数据，有效地使驱动链成为比特币的一部分，而无需明确的软分叉决定来修改比特币的规则。
这个特殊的子话题得到了扩展的讨论，并出现了一个 跑题 话题当大部分挖矿算力都在试图窃取比特币的时候比较驱动链安全性和LN的安全性。
● 为洋葱消息付费：Olaoluwa Osuntokun 本周向Lightning-Dev邮件列表 发布 允许节点购买带宽来发送洋葱消息。先前提议的洋葱消息协议允许一个节点在不使用 HTLC的情况下通过 LN 路由向另一个节点发送消息。用基于 HTLC 的洋葱消息来发送keysend风格的消息的优点是：洋葱消息不需要临时锁定任何比特币，从而使成本更低和更灵活（例如，洋葱消息可以在对等方之间发送，即使它们不需要）。然而，无成本就能发送洋葱消息使一些开发人员担心它们将被用于在 LN 上免费中继流量，这使得运营 LN 节点的成本更高，并让大量节点有动力禁用洋葱消息中继。如果洋葱消息用于节点之间的重要通信，例如为 offers提出的重要通信，成本可能会变得特别问题。
Osuntokun 建议节点可以为他们想要使用的洋葱消息带宽预付费用。 例如，如果 Alice 想通过 Bob 和 Carol 将 10 kB 的数据路由到 Zed，她将首先使用 AMP 向 Bob 和 Carol 支付 至少 10 kB 的带宽，以它们各自节点公布的消息中继速率。 在向 Bob 和 Carol 付款时，Alice 向他们每个人注册一个唯一的会话 ID，并将该 ID 包含在她要求他们为她中继的加密消息中。 如果 Alice 支付的金额足以满足她的消息使用的带宽，Bob 和 Carol 将参与将消息转发给 Zed。
Rusty Russel 回复到 有几个批评，最值得注意的是：
HTLC 目前已经是免费的：对免费洋葱消息中继的担忧的主要反驳一直是，使用 HTLC 在 LN 上中继流量基本上是免费的。1 不过，目前尚不清楚这种情况是否会永久保持—— 许多修复 channel jamming 攻击的建议建议对失败的 HTLC 收费，这些 HTLC 目前可用于自由路由数据。
会话标识符降低了隐私：在前面的示例中，Alice 向 Bob 和 Carol 注册的会话标识符允许他们知道哪些消息来自同一用户。相反，如果没有会话 ID，他们将不知道不同的消息是来自同一个用户还是不同的用户都使用同一路由的一部分。 Russell 指出，他在处理洋葱消息时曾考虑过盲标记，但他担心它“会很快变得复杂”。
相反，Russell 建议简单地限制节点转发的洋葱消息的数量（不同类别的对等节点有不同的限制）。
比特币核心代码评审俱乐部
打开 p2p 连接到侦听非默认端口的节点 是 Vasil Dimov 的 PR，用于在选择出站对等点时取消端口 8333 的优先处理。 参与者讨论了比特币核心的自动连接行为、没有默认端口的网络的好处，以及避免使用某些端口的理由。
8333是默认端口的历史原因是什么？
这种行为一直存在，但中本聪的动机尚不确定。 常见的民间传说表明，它通过八卦其地址来防止利用比特币网络对服务进行 DoS，但这不是实际的历史原因。 另一种传闻的解释是，默认端口可能有助于防止攻击者控制节点的 IP 地址表，从而防止使用单个 IP 地址和多个端口的 P2P 连接（我们现在称之为 eclipse 攻击）。
用这个 PR 去掉 8333 端口的优惠待遇有什么好处？
过滤和存储潜在对等点的 IP 地址的最初方法并不像现在这样复杂。现在，我们通过地址的网络组、AS、源对等方等来限制我们存储的 IP 地址的数量。 我们还对我们处理和中继的地址数量进行速率限制。鉴于地址管理器（“addrman”）和地址中继的这些更改，优惠待遇对防止日蚀和 DoS 攻击几乎没有影响。此外，对默认端口的偏好意味着很少有连接到侦听非默认端口的节点。这也是一种隐私泄露，让本地网络管理员可以轻松检测比特币网络流量 - 只需查找端口 8333。如果政府希望禁止比特币，指示 ISP 记录和/或阻止单个端口的流量比简单得多 试图通过监控所有连接上发送和接收的数据来识别比特币流量
在这个更改之前，并不鼓励自动连接到侦听非默认端口的对等方，但并非不可能。 在什么情况下节点仍会连接到这样的对等点?
在自动连接逻辑中，节点尝试连接到从其地址管理器中随机选择的地址。 如果 50 次尝试后没有连接成功，它将开始考虑非默认地址。 一位参与者指出，功能测试中的节点也不使用默认端口，但有人指出，这些节点是使用手动连接连接的，而不是自动出站连接。
在此 PR 之后，默认端口仍然在 Bitcoin Core 中发挥作用。 还在哪里使用?
如果未明确提供端口，则使用默认端口。这与种子DNS特别相关，新节点使用这些种子来引导其地址管理器。完全废弃默认端口的概念需要寻找替代方案，因为 DNS的任务是将域名解析为IP地址，而不是提供服务的地址和端口。
允许调用者将盐值传递给 CServiceHash，然后在提交 d0abce9 中使用 CServiceHash(0, 0) 对其进行初始化的原因是什么？
节点大约每 24 小时公布一次自己的地址，每个节点都会传播传闻中的地址，以帮助网络周围的节点发现新的节点。此代码使用IP地址和当前时间的哈希值随机选择一个或两个对等方来转发最近收到的地址。但是，我们不希望通过多次发送来促进传播地址。因此，我们使用相同的salt(0, 0)和一天的时间戳粒度。
发布版和发布预览版
● LDK 0.0.105 除了提供许多其他功能和错误修复（包括两个潜在的 DoS 漏洞）外，还增加了对虚拟节点支付的支持（参见 Newsletter #188）和更好的概率支付路径查找（参见 Newsletter #186）。
值得注意的代码和文档变化
本周值得注意的代码变化 Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface HWI, Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), 和 Lightning BOLTs.
● Bitcoin Core #23542 消除了 Bitcoin Core 只连接到默认比特币端口（主网为 8333）上的对等点的偏好。 相反，比特币核心将在任何端口上打开与对等点的连接，除了已知被其他服务使用的几十个端口。 端口 8333 仍然是 Bitcoin Core 在本地绑定的默认端口，因此只有覆盖默认值的节点才会通告它们接受其他端口上的连接。 有关此更改的一些其他信息可以在本通讯前面的比特币核心公关评论俱乐部摘要中找到。
● BDK #537 将钱包地址缓存重构为公共函数。以前，确保钱包内部数据库加载和缓存地址的唯一方法是通过内部函数——这意味着离线钱包没有确保数据库加载地址的机制。 此补丁支持使用案例，例如将离线钱包用作多重签名者和验证零钱地址。 相关地，BDK #522 为内部地址添加了一个 API，这对于应用程序创建一个将输出拆分为几个较小的事务的事务很有用。
脚注
- 当用户 Alice 通过路由节点 Bob 和 Carol 将基于 HTLC 的密钥发送消息中继给用户 Zed 时，Alice 可以使用不知道原像的哈希构造 HTLC，保证它不会失败，因此 Bob 和 Carol 都不会收到任何钱。 Alice 发送此类消息所承担的唯一成本是创建通道（如果她创建了它）和随后关闭它（如果她负责支付这些成本）的成本 - 加上攻击者窃取私钥的风险 用于她的 LN 热钱包或任何其他可能危及她的 LN 通道的数据。 对于具有长寿命通道的安全且无错误的节点，这些成本应该基本上为零，因此基于 HTLC 的密钥发送消息目前可以被认为是免费的。