在过去的几周里，许多人一直在讨论即将发布的比特币核心版本 24.0 以及代码库将如何包含完全按费用替换 (RBF) 逻辑。 由于一些闪电网络和零确认倡导者表达了对全 RBF 想法的厌恶，该讨论已引起争议。 Synonym 的首席执行官 John Carvalho 一直在 Twitter 上直言不讳地批评该提议，并且在 11 月 3 日，Carvalho 表示核心开发人员的一个子集“目前正试图通过强制宠物议程进行所有交易 RBF 来攻击比特币默认。”
比特币核心版本 24.0 提供全 RBF 逻辑、零确认和闪电网络支持者公开反对该提案
自从软件开发人员 Peter Todd 于 2014 年推出费用替代 (RBF) 以来，这个话题一直是一个敏感话题。 从本质上讲，RBF 允许比特币用户利用该功能，以便将未经确认的交易替换为费用增加的替代交易。 但是，当一个交易被包含在一个区块中时，它不能被 RBF 取代。 该方案仅适用于零确认 (0-conf) 交易 (txns)。 零确认交易是商家或服务可以通过网络广播接受的转账，远在矿工确认区块中的交易之前。
根据各种报道，Bitcoin Core 24.0 版将提供全 RBF 逻辑，这一想法引发了更多争议。 “到目前为止，比特币核心节点应用了‘先见’规则，这意味着节点的内存池 (mempool) 中不会接受冲突的交易并将其转发给对等方，”比特币杂志详细描述的摘要。 “随着这个即将发布的版本，如果他们包含的费用高于与他们冲突的早期交易，用户可以选择让他们的节点接受并转发冲突交易。”
但是，比特币杂志的摘要不包括反对全 RBF 逻辑的有争议的论点。 许多批评者表示，交易替换会损害网络，并有助于促进双花攻击。 自从 RBF 首次引入比特币核心版本 0.12 以来，双花攻击断言一直存在争议。 在 10 月 29 日发表的一篇关于比特币核心版本 24.0 的摘要中，作者提到了一些反对完整 RBF 方案的批评者和论点。 作者引用了闪电网络（LN）钱包 Muun 的创始人 Dario Sneidermanis。
“在过去的几天里，我们一直在调查最新的比特币核心候选版本，我们发现了一些关于部署选择加入全 RBF 的令人担忧的事实，”Sneidermanis 解释说。 Muun 首席执行官进一步补充说，“零配置应用程序（如 Muun）现在必须立即禁用零配置功能。” Sneidermanis 对拟议变更的批评仍在继续：
我们 Muun 将不得不为超过 100,000 名用户关闭出站闪电支付，这是目前所有非信托闪电支付的很大一部分。
Synonym 首席执行官 John Carvalho 表示，RBF 让“消费比特币对消费者和企业来说更加危险”
描述比特币核心版本 24.0 的 Medium 帖子还提到了不同意 Muun 首席执行官分析的人。 例如，比特币核心开发人员大卫哈丁表示，升级“不会以任何重大方式改变交易可替代性”。 博客文章详细介绍了“Pieter Wuile 提出了类似的论点”，软件开发人员 Luke Dashjr 已经在他的软件 Bitcoin Knots 代码库中实现了全 RBF 逻辑。 在 Medium 帖子发表几天后，Synonym 的 CEO， 约翰·卡瓦略，关于讨论的推文，他包括了一些指控。
“核心开发者的一个子集目前正试图通过强制宠物议程默认使所有交易 RBF 来攻击比特币，”卡瓦略 写了 2022 年 11 月 3 日。“这次攻击包括比特币开发者邮件列表的谎言和游说、核心节点的代码更改以及对矿工的贿赂尝试。 商家依靠 0-conf txns 作为满足商业消费者需求的一种方式。 RBF 使内存池变得不那么可靠，并且花费比特币对消费者和企业来说更加危险，”Carvalho 添加.
花费 BTC 的用户越多，它的价值就越高。
— 约翰·卡瓦略（@BitcoinErrorLog） 2022 年 11 月 4 日
卡瓦略的意见遭到争议，一位用户 发推文 “当大多数链上交易在未来只会是非常大的价值交易时，依赖 0-conf 交易似乎不是很聪明。” 卡瓦略 回应 并坚称“其他人可以接受多少风险不是你的决定。” 另一个人 告诉 卡瓦略认为全 RBF “似乎 [like a] LN 的良好激励和 L1 腹胀减少。 中间时间 [obvious] 商家的痛苦。 但对于大多数商家来说，非 RBF 永远不会保持盈利。”
Synonym CEO 回复说 强调：
这是与可观察到的现实相冲突的主张和预测。
绝大多数反对票否决了卡瓦略的论点，彼得托德说矿工已经联系他要求全 RBF
同一天，卡瓦略 问 人们证明“双花总是很容易和可能的。” “证明这一点，”同义词首席执行官评论道。 “[Double spend] 在 [Bitrefill]，他们确实想要测试示例。” 第二天，卡瓦略 假如 他的 RBF “论证和解决方案，简化，没有感觉。”
Carvalho 在 Github 上发表的论点遭到大量 NACK（投票否决）的驳斥，一位人士表示：“作为一个曾经有过交易卡住的人，能够轻松进行 RBF 对用户来说是最好的体验。” 另一个人详细说明他认为 0-conf 交易不安全并表示：
[NACK] zero-conf 并不安全，让 RBF 更难一点点是妄想。
软件开发人员 彼得·托德 一直在反对 Carvalho 在 Github 上的论点，并解释说比特币矿工联系了他。 “矿工最近联系了我个人，询问他们如何转向 [full RBF] 上。 显然，将他们指向一个配置选项对他们来说是最简单的，”托德告诉卡瓦略。 此外，Todd 强调需要完整的 RBF 功能。 “显然需要这种选择，”托德说。 “似乎删除它的动机来自试图使零配置更安全，”软件开发人员补充道。
操作手柄“Greenaddress”的Github用户写道：“NACK。 我计划在个人和生产环境中使用这个功能，例如在 esplora/blockstream.info 和 Green wallet。” Greenaddress 进一步批评了费用替代标志机制。
“正如其他人所说，我们也可以编译比特币核心，但这会带来不便，总的来说，我认为 [RBF] 标志提供了一种虚假的安全感，尤其是我们最近看到，即使是非标准交易也可以找到它们的 [way] 给矿工。 大多同意 afilini/ptodd/dbrozzoni 的观点，”Greenaddress 总结道。 然而，有人质疑 Greenaddress 背后的目的，称它计划“在个人和生产中使用此功能”。
“出于什么目的？” 个人 问 Github 上的绿色地址。 “我还没有看到‘是’的答案 [full-RBF] 提供除破坏以外的任何好处 [zero-conf] 商业惯例？ 如果是这样，它们是什么？ 然而; 以上是否暗示你有一个？
您如何看待围绕开发人员提议添加到比特币核心代码库的完整 RBF 功能的争议？ 您如何看待 Sneidermanis 和 Carvalho 反对完整 RBF 逻辑的论点？ 在下面的评论部分让我们知道您对此主题的看法。
