比特币 - 完全RBF - Glozow

完整 RBF

免责声明：这是我通过阅读所有能找到的资料并尽可能多地与人交流后，个人的理解。当我给出自己的观点时，我会加以说明。否则，我试图保持开放和公正的态度，但可能存在无意的偏见。

背景

RBF 和完整 RBF

手续费替换 (Replace-by-Fee, RBF) 是一种 mempool 策略，允许节点根据交易费率在冲突的未确认交易之间做出选择。在此策略之前，mempool 接受它首先看到的任何交易。

• Bitcoin Core #6871
• BIP 125
• Bitcoin Core 从 0.12.0 版本开始使用选择加入 (BIP 125) 的 RBF

完整 RBF 的定义已经随时间变化。在本文档中，它指的是一种接受交易替换的策略，即使原始交易没有发出 BIP125 可替换信号。

最近

2021 年 6 月：Antoine Riard 发表了一项关于在 v24.0 中添加 -mempoolfullrbf 选项的计划 (计划于 2022 年 9 月/10 月)，征求意见和疑虑。

• optech 总结
• 邮件列表帖子

2022 年 6 月：Antoine Riard 打开了 #25353 以添加 -mempoolfullrbf 选项

• optech 总结

2022 年 7 月：Bitcoin Core 合并了 #25353

• optech 总结

2022 年 10 月：Dario Sneidermanis 在 Bitcoin Core 中发布了关于完整 RBF 和 -mempoolfullrbf 选项的担忧，认为这会给接受未确认交易作为最终结果的企业带来问题。他要求从 v24.0 中删除 -mempoolfullrbf 选项，以便给 Muun 和其他应用程序更多的时间来准备。

• optech 总结
• 邮件列表帖子

这篇文章引发了各种讨论和邮件列表帖子，主要是关于一般的完整 RBF：

• 许多人 回复 强调 Bitcoin Core 默认的 RBF 策略没有改变。
• Anthony Towns 发帖 同意网络范围内部署完整 RBF 的想法，而不仅仅是个人节点选项。他建议，作为给协议测试时间和给企业适应时间的一种方式，暂时将该选项限制为仅在测试网上使用，并创建在主网上部署默认的真正完整 RBF 的时间表。
• Sergej Kotliar 发帖 讨论了完整 RBF 的问题，不同意双重支付风险已经很高以及闪电网络可以取代链上 "零确认" 支付的观点。他提供了一些来自 Bitrefill 经验的数据。他说，在实践中，"不到百万分之一 "的双重支付尝试会成功。他指出，他们的支付中只有 15% 使用闪电网络，而过去默认使用 bech32 的实验只会赶走用户。他预计，如果 Bitrefill 停止接受未确认的支付，"目前 85% 的链上比特币用户将不再使用比特币。"
• John Carvalho 发帖 讨论了一般 RBF 的问题，认为它使零确认支付的风险更难以管理。在上面提到的同一篇帖子中，Sergej Kotliar 也将免费期权问题描述为一般替换的问题之一。请参阅下面的美式看涨期权部分。

几个与完整 RBF 相关的拉取请求已提交给 Bitcoin Core。

• #26287 实现了在主网上删除该选项的请求。在遭到几位审查员的反对后，它被关闭了。
• #26323 是默认启用完整 RBF 的 PR，但有一个预定的时间 (2023 年 5 月 1 日)。如果用户设置了 -mempoolfullrbf=1 选项，它不会在那之前生效。用户也可以设置 -mempoolfullrbf=0 选项，以继续要求在那天之后发出信号。
• #26305 是默认启用完整 RBF 的 PR，实现了 Antoine 发布到邮件列表的第二部分。它不适用于 v24.0。大多数审查员表示概念上 ACK 适用于 v25.0 或以后的某个时间。

总结

这是我在阅读和与人一对一交流后对情况的理解。仍然有一些我没能联系到的人，这里可能有一些偏见，但我已经尽力了，如果我不公平地代表了任何人的论点，我深表歉意。

一般的完整 RBF

似乎有 3 种思想流派：

1. 我们应该积极地朝着完整 RBF 发展

2. 我们现在应该努力阻止完整 RBF，但最终还是会走到那一步

3. 我们应该努力阻止完整 RBF 发生

第一个立场主要由协议开发者持有，第二个立场由一些企业持有。最后的立场似乎非常罕见。

为什么我们应该积极地朝着完整 RBF 发展

1. 完整 RBF 是网络的自然状态。比特币区块、PoW 等的目的是解决双重支付问题；未确认的交易从未得到任何保证。当矿工收到两个冲突的交易时，激励兼容的策略是选择给他们更高费用的交易。使用 RBF 策略有助于节点更准确地了解哪笔交易可能被确认。当非信号交易具有更高费率的冲突时，"矿工会很好 "的安全假设明显弱于 "矿工会做理性的事情"。

2. 完整 RBF 已经可以观察到，所以我们应该准备好更新我们的 mempool 策略，以便更准确地了解将被挖掘的内容。如果完整 RBF 变得普遍，而我的节点仍然假设选择加入得到遵守，它将拒绝可能被挖掘的交易，并可能使我对双重支付的尝试视而不见。

3. 启用完整 RBF 可以消除各种基于信号的 DoS/pinning 攻击。

常见的反驳：

• 接受未确认的交易作为最终结果实际上在实践中是安全的。
• 闪电网络攻击在实践中也很少见。

为什么我们现在应该努力阻止完整 RBF

1. 完整 RBF 将为接受未确认交易作为最终交易结果的企业带来更高的双重支付风险。在理论上，接受非信号未确认交易是不安全的，但在实践中，它目前非常安全，并且是比特币用户发送快速支付的常用方式。闪电网络存在，但生态系统仍在构建技术和用户体验层，以使该选项可供许多用户访问，并且采用率仍然很低。删除使用链上未确认交易的选项可能实际上不会鼓励闪电网络的采用，而是会赶走用户。Dario Sneidermanis 帖子

常见的反驳：

• 零确认实际上并不安全；今天有可能发生双重支付。
• 如果零确认在实践中是安全的，那真的不是因为没有发生完整 RBF，而是因为企业正在采取预防措施，例如要求高费用和等待 以检测其他(有时是许多)mempools 中竞争冲突的交易。在法律上，企业通常也受到保护，免受用户双重支付。

为什么我们应该努力阻止完整 RBF 发生

1. 一般来说，RBF 为接受未确认交易作为最终交易结果的企业带来了更高的双重支付风险。目前的风险接近于零。这些企业应该能够继续做出这些假设，因为它能够实现 "快速 "链上支付。

2. 美式看涨期权：如果在交易创建和确认之间汇率发生变化，用户可以替换交易以 "取消 "它并创建一个新交易。

常见的反驳：

• 完整 RBF 是不可避免的，尤其是当费用成为区块奖励中更重要的组成部分时。试图强迫人们做激励不兼容的事情在去中心化的网络中是无意义和不切实际的。Russell O'Connor 帖子,Antoine Riard 帖子
• 免费看涨期权今天已经存在，具有选择加入 RBF，并且可能有其他解决方案。

-mempoolfullrbf 选项

为什么我们现在应该删除 -mempoolfullrbf 选项

1. 该选项的存在与 Bitcoin Core 对其的认可无法区分。Bitcoin Core 没有默认启用它，但是通过添加该选项，表明用户拥有此选项是安全的。

2. 添加该选项使运行完整 RBF 变得更容易，因此矿工 将 启用它，从而增加了非信号替换在实践中传播的机会。只有少数人就足以进行非信号替换。Dario Sneidermanis 帖子

3. 如果这导致在企业准备好之前就实现了完整 RBF，它们可能会受到攻击和/或被迫缩小其 (许多) 用户的选择范围。这对 Bitcoin 来说可能是不利的。

为什么我们应该保留 -mempoolfullrbf

1. 软件产品的用户不应能够剥夺其他用户的选择权。我们有一些用户说 "我想要配置我的个人节点来执行此操作的选项"，而另一些用户说 "我不希望其他用户拥有此选项，因为 _。" 说 "是的，对不起，你不能拥有此功能，不是因为我们无法支持它，而是因为另一个用户这样说 " 似乎是不合理的。

2. 这是让 Bitcoin Core 对个人节点运营商的决定负责。它没有改变默认行为。它添加了一个选项。拥有此选项并不意味着会发生完整 RBF；即使我们删除它，仍然可能发生完整 RBF。Pieter Wuille 帖子

常见的反驳：

• 如果添加该选项无关紧要，那么删除它也应该无关紧要。Anthony Towns 帖子

问题和事实上的分歧

我认为值得专门用一个章节来介绍这些根本性的分歧，因为它们导致人们在许多讨论中各说各话。

• 完整 RBF 在网络上的普及程度
  • Peter Todd 报告 说，他已经观察到使用 opentimestamps 替换非信号交易。他指出，这些替换很少见，并且这些替换可能是由于其他因素造成的。
  • 他还在 2016 年发布 了关于此事的帖子。那个帖子的内容与今年的讨论类似。
• 通过接受 "零确认 "进行双重支付的当前风险
• 比特币生态系统中对 RBF 和闪电网络的支持程度
• Bitcoin Core 给出了多少 的 "通知"
  • Murch 和其他人 (特别是在 irc 会议 期间) 说 "我们已经讨论完整 rbf 七年了。"
  • Antoine Riard 在 2021 年 6 月将帖子 发送到邮件列表，比该选项合并早一年多。
  • David Harding 指出，该帖子可能没有完全捕捉到添加该选项的潜在影响和 风险。许多人认为它可能直接导致完整 RBF 在网络上很常见，因此应该传达给企业，它们必须为此做好准备。

我有一些悬而未决的问题，并且非常希望能够向矿工提出这些问题：

• 如果 v24.0 包含 -mempoolfullrbf 选项，是否会有矿工启用它？如果是，多久启用？
• 如果我们删除了 -mempoolfullrbf 选项，是否仍然会有矿工最终进行完整 RBF (例如，使用补丁运行)？

前进方向

检测网络上的完整 RBF

我们应该尝试监控完整 RBF 在网络上的普及程度，因为如果看到非信号替换变得非常普遍，我们应该坚定地建议启用 -mempoolfullrbf=1。需要关注的一些事项：

• Peter Todd 的 opentimestamps。每笔交易都列出了其费用；任何高于 182sat 的费用都是非信号替换。
• 非信号替换的个别实验。
• 对 Muun、Bitrefill 和接受未确认交易作为最终结果的企业的双重支付尝试。
• 其他软件中的完整 RBF。例如，实施完整 RBF 或添加行为以假设替换可以在没有信号的情况下发生。

Bitcoin Core v24.0

Bitcoin Core v24.0 计划 于 2022 年 10 月 19 日发布。错误修复也推迟了发布，但我认为这是最后一个障碍。我不认为 "我们太接近了，无法更改任何内容 "是一个好的论点，但是存在紧迫性。

完整 RBF 在每周的 bitcoin-core-dev irc 会议中讨论 过。没有做出合并或推进任何 PR #26323 或 #26287 的决定。许多人支持 #26305，但时间更长 (从现在起 1-2 个版本或 1-2 年)。许多人不喜欢从用户那里删除一个选项的想法，特别是如果该选项是人们想要的并且对个人节点运营商来说是安全的做法。

对我来说，最大的问题是 "添加此选项是否会导致矿工切换到完整 RBF? "，我认为这需要由矿工来回答，而不是通过推测。就像完整 RBF 的支持者不能明确地说 "矿工会这样做，因为这是理性的 "一样，我不认为人们可以说 "矿工会这样做，因为它很容易翻转配置。"

Dario 从 Muun 的角度发布了对可用 PR 的 分析。它明确地支持完整 RBF，但对某些可预测性感兴趣。例如，如果预计每个人都会在从现在起大约 6 个月后的预定时间切换到完整 RBF，那么 Muun 有时间来实施和部署他们的解决方案。

推广时间表

多人提出了协调部署完整 RBF 的时间表：

• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021026.html
• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021017.html
• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021099.html
• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021101.html

我个人也认为，部署完整 RBF 最安全的方法是以协调的方式进行，与人们同意生态系统已准备就绪的时间保持一致。虽然这不是共识变更，但对于网络上的每个人来说，在同一时间切换更为安全。

如前所述，如果网络上开始发生完整 RBF，并且大多数 Bitcoin Core 用户没有办法配置他们的节点以接受非信号替换，那么他们的 mempool 就会变得不准确。即使我们密切监控网络并且矿工主动沟通他们正在接受非信号替换，让节点自动切换也比尝试告诉每个人使用 -mempoolfullrbf=1 重新启动安全得多。

时间表会给企业带来压力，要求它们弄清楚技术和用户体验方面的事情，但在我看来，大约 2 年的时间是非常合理的。同样，如果矿工计划在 2024 年减半后切换到完整 RBF (即，因为随着补贴的减少，费用变得更加重要)，这将与他们的计划相符，因此 (我认为) 他们可能不会觉得有必要通过补丁来做到这一点。

但是，我也认为，合并某种超时锁定激活可能会导致大量指责 Bitcoin Core 试图强制执行完整 RBF 的指责。试图问会受到完整 RBF 影响的企业 "你什么时候可能准备好使用完整 RBF? "似乎总是会得到 "永远不会! "虽然我认为仍然值得尝试。

需要帮助处理完整 RBF 的企业

支付替换检测

支付替换预防

• 原文链接： github.com/glozow/bitcoi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～