「过滤」比特币铭文的 PR 贴下，开发者们有哪些正反观点...

整理： gloria

编译：GaryMa，吴说区块链

背景

2023 年 9 月，比特币开发者 Luke Dashjr 向 Bitcoin Core Github 仓库提交 PR， 即更新「datacarriersize」以过滤「铭文」这类携带新型脚本数据的交易，背后对应的价值观是认为「铭文」交易属于漏洞攻击，应当修复禁止。

默认情况下，Bitcoin Core 对未确认交易的 OP_RETURN 输出数量和嵌入的数据量进行限制，其默认值为 80 字节。通过配置 -datacarriersize 选项，用户可以更改对数据量的限制。然而，目前该选项仅适用于 OP_RETURN 输出。

该 PR 的改动使得配置了 -datacarriersize 的用户不仅能够限制 OP_RETURN 输出中的数据量，还能够限制嵌入见证数据的数量。

需要注意的是，该 PR 并未实现一种全面的方式来识别见证数据中的「任意」嵌入数据（因为目前没有一种确定的方法来实现这一点）。它主要检查了针对铭文数据的 OP_FALSE OP_IF ... OP_ENDIF 结构。这个结构通常用于处理铭文数据。

尽管该 PR 下也有大量开发者对此展开讨论，但 Bitcoin Core 代码维护者 achow101 于 2024 年 1 月 5 日正式关闭该 PR，achow101 最后陈词表示，（Luke 提出的）这个 PR 是有争议的，这一点非常明显，并且在目前的状态下，没有希望达到一个对所有人都可接受的结论；在这个时刻，我看不出有任何理由保持它开放的状态，并继续发送通知，以维持那些不断来回的僵持不下的讨论。

Bitcoin Core 另一位代码维护者 gloria 将针对这一话题的开发者正反两方观点进行汇总，吴说编译如下。

支持禁止「铭文」的观点

1、「禁止铭文，这是一种垃圾交易」

这些类型的交易用于 ordinals、NFT、数据携带或一些非金融交易的用例。这种流量是「垃圾交易」，由于高交易流量和费用，它破坏了比特币用于支付的使用。

● 这些垃圾交易使得比特币的真正用途越来越难以使用。

● 插入数据是对 taproot 脚本的一种欺骗和滥用。

● 能够嵌入随机字节是一种「漏洞」 。

● 如果比特币是货币（它是！）...那么非货币交易应该尽可能减少。

● 对 ordinals 的欢呼者是以太坊\反比特币极端主义者，那些呼喊「我们需要改变比特币文化」的人，是浪费时间的喷子。

● 这是对网络的误用，它是为金融交易（白皮书、名称和代码指向这一点）而设计的，数据存储并不是一个预期的用例。

● 这导致了「网络拥堵」和「更高的费用或更慢的处理时间」，这是一种「DDoS 攻击」。

● 问题不在于铭文，而在于高昂的手续费。

● 比特币网络需要立即得到保护，避免垃圾交易攻击。

2、「铭文和嵌入的数据损害了网络」

这些类型的交易加重了节点运营商的成本，以某种方式损害了网络。

● 该 PR 所针对的交易，就是普通节点运营商所承受不住的重要成本来源之一。

● 这些交易通过增加运营节点的成本影响网络的去中心化。

● 这导致直接在区块链上存储了不成比例和过多的大数据。

3、「禁止是用户的需求」

显然，用户有需求和特定的用例，因此 Bitcoin Core 应该提供这个选项。否则，人们会自行编写运行补丁，这可能是不安全的。

● 节点运行者需要一个内置选项来忽略所有现代形式的数据携带，这样他们就不必手动修补他们的节点。

● 如果开发者不帮助节点运行者保护自己免受这种攻击，他们可能不得不诉诸不当手段来加强防御。

● 我想控制我的内存池政策，我想决定什么是垃圾交易，什么不是。

● 如果矿工认为比特币是货币而不仅仅是一个无需许可的、不可更改的区块链，他们确实会过滤垃圾交易以使货币网络可用，因此矿工会希望有这个功能。

4、「这只是修复 datacarriersize 以如期工作」

我们限制了 OP_RETURN 中的数据携带。这应该适用于所有嵌入交易中任意数据的方法。这一直是 -datacarriersize 的「意图」，因此这是一个「错误修复」。

● luke-jr 认为 -datacarriersize 没有随着 segwit 和 taproot 的引入而更新其他类型的数据携带是一个错误，并将此定义为错误 / 漏洞。

● Bitcoin Core 已经标准化了插入超过 83 字节的任意数据和铭文的插入是绕过此限制的一种变通方式，因此这是一个错误修复。

● 垃圾交易已经在代码的各个层面上被过滤了，而且这样做已经超过十年了。所有这个 PR 做的就是将一个现有的 datacarriersize 限制应用于一种不同形式的数据携带，这显然是一个意料之外的漏洞。

● 如果不是对交易中存储的任意数据施加限制，那么数据载体限制的目的是什么？

● 这个标准化规则的目的不仅仅是针对原始 scriptPubKey 中包含的数据，而是针对所有形式的任意数据。

反对禁止「铭文」的观点

1、「这并阻止不了铭文」

这不会阻止铭文。由于它不具有激励兼容性，因此矿工（以及铭文的用户当然）不太可能采用这种政策，这意味着它在阻止这些交易方面的效果很小。

● 如果只有 Ocean 池使用这个并且它仍然是一个相对较小的池，它将没有效果。如果它被广泛部署，绕过它也是很容易的。

● 从长远来看，这对矿工来说是激励不兼容的。

● 矿工不太可能放弃那个收入来源。审查这些交易只会鼓励私人内存池的发展。

● ordinals 交易最终会进入区块链，绕过内存池，所以这个 PR 对于解决 / 缓解问题没有作用。

● 在某种程度上，这是一种尝试不仅不监控这些交易，而且还试图阻止它们的使用，这最多会导致这些交易绕过实施这个的节点，或者在最坏的情况下导致直接提交给矿工的交易实践，这对挖矿的中心化有严重风险。

● 铭文爱好者可以通过确保网络上的少数节点不过滤铭文来维护铭文在网络上的传播。

● 显而易见，这必然导致从过滤内存池中构建的区块模板的总区块奖励比从所有未确认交易中构建的区块模板低。这意味着任何过滤铭文的矿工都是在减少自己的收入，从而使不过滤矿工受益。

2、「我们不能编写代码来检测所有嵌入式数据」

一般来说，我们无法阻止嵌入任意数据的交易。铭文存在于众多嵌入数据的方式中（我们永远无法完全涵盖）。最好是保留最有效率的方法，即那些对网络资源成本影响最小的方法。

● 没有一种通用的方法可以过滤所有当前和未来的数据携带方式。这会在非常关键的代码路径中引发无休止的猫鼠游戏。

● 试图阻止所有类型的数据嵌入将导致这段代码变得越来越复杂。每次发生这种情况时，都会对维护者施加很大的压力，迫使他们迅速推进‘停止垃圾交易。

● 据我所知，没有合理的方法可以阻止人们在见证（witnesses）中存储任意数据，而不激励更糟糕的行为和 / 或破坏合法的使用案例。

3、「此更改可能有害」

这个 PR，它改变了默认的内存池策略，可能对独立节点运行者和网络有害。

● 排除将被挖掘的交易对节点是有害的。参与交易中继和拥有内存池的意义在于能够预测下一个区块的样子。故意排除那些存在非常明确（尽管愚蠢）的经济需求的交易，破坏了这种能力。

● 最终，运行此补丁的用户仍然处理包括铭文的区块。他们只会损害自己的费率估算，减慢区块验证速度，且对其他节点的有用性降低。

● 通常更改默认政策是危险的。使先前标准的交易变为非标准意味着现在有些人可能会发现访问他们的资金变得更加困难。通过改变默认值，而不是选择加入，它代表了对依赖 Bitcoin Core 构建区块模板的矿工的潜在破坏性和不受欢迎的行为变化... 这将代表一种温和的没收形式，应当避免。

4、其他反对该 PR 的观点

● 一般而言，使用内存池政策来阻止使用现在已经无效，尽管它过去曾被以这种方式使用。虽然历史上非标准性已被用来阻止一些繁重的操作，我相信：

○ 这在这些满区块空间已成常态的情况下远不太相关，因为它无论如何都不会减少节点运营成本。

○ 无力阻止已经存在市场的交易，这些交易每天支付数十个 BTC 的手续费。

● 基于用例「审查」交易的尝试是不恰当的。自由市场决定比特币的用途。我们无权告诉人们应该如何使用比特币。如果你认为你的设计更加优雅，那就去做吧，让自由市场决定哪个更好。

● 比特币是一个去中心化的无需许可的网络...任何人都可以以他们想要的方式使用他们的比特币，无论出于什么原因这种用途多么令人反感。

● 这改变了 -datacarriersize 的作用，除了改变默认政策，它将 OP_RETURN 输出大小的政策和新的嵌入冗余脚本代码中的数据限制捆绑在一起，使得无法配置你的节点以匹配 26.0 及更早版本的默认政策。