Damus的创始人JB55公开发表文章，他将作为反对者参加关于序数铭文对比特币是否有益的讨论。JB55对铭文的技术细节进行了研究，并开始理解Luke关于如何利用比特币的反数据垃圾机制中的漏洞的观点。

比特币实际上是一个数据库，但是它是有史以来性能最差的数据库之一，同时也具有一些独特的属性。每当你拥有一个数据库和一种脚本语言，聪明的开发人员就会找出如何利用它的方法，通常这是出乎意料的。试图阻止他们通常会变成一场打地鼠的游戏。

这个游戏是如何展开的呢？对序数铭文以及比特币中打击数据垃圾邮件的技术分析和历史回顾也许会有一些启发。原文链接。

将数据存储在比特币中的“标准”方法

你将“数据”添加到比特币中的标准方式是调用OP_RETURN操作码。比特币开发人员注意到人们通过大型多重签名交易将数据（例如比特币白皮书）存储在utxo集中。这样做的问题是，这个集合是不可删除的，并且可能随着时间的推移而增长。另一方面，OP_RETURN输出是可以被证明删除的，不会增加utxo的膨胀。

以下是2014年3月0.9.0版本发布说明的摘录，讨论了这个问题：

*关于OP_RETURN：社区中存在一些混淆和误解，关于0.9版本和区块链中的数据的OP_RETURN功能。这个变化并不是支持将数据存储在区块链中的意见。OP_RETURN的变化创建了一个可以被证明删除的输出，以避免数据存储方案（其中一些已经部署）将任意数据，如图像，存储为永远无法花费的TX输出，从而膨胀了比特币的UTXO数据库。

在区块链中存储任意数据仍然是一个糟糕的主意；在其他地方存储非货币数据更加经济和高效。*

比特币核心的许多工作都集中在确保在人们试图滥用它来存储数据等方面，系统继续以分散的方式为其预期目的运行。比特币核心一直不鼓励这样做，因为它不是为存储图像和数据而设计的，而是用于在网络空间中移动数字货币。

为了帮助激励人们不要做愚蠢的事情，OP_RETURN交易没有变为非标准，以便它们可以被节点和矿工中继，但有一个附带条件：

*它们只能推送40字节（后来增加到80、83字节，我猜是为了支持更大的根默克尔哈希，因为这是op_return的唯一明智的用例） 比特币还添加了一个名为“-datacarriersize”的选项，它限制了从这些输出中中继或挖掘的字节总数。 *

为什么铭文在技术上是一种漏洞

铭文通过在OP_IF块内部使用OP_PUSH将数据伪装成比特币脚本程序数据，以绕过datacarriersize限制。序数不使用OP_RETURN，并且不受datacarriersize限制的约束，因此节点运行者和矿工目前对他们希望中继和包含在块中的数据的总大小具有有限的控制权。Luke的比特币核心分支有一些选项来抵制这种垃圾邮件，所以希望很快也能在核心中看到这一点。

铭文还利用了segwit v1（见证折扣）和v2/taproot（没有任意脚本大小限制）中的功能。这些功能都有有趣且有充分理由引入的原因。

见证折扣的目的是降低花费许多输出的成本，有助于减小utxo集的大小。铭文利用了这个折扣来存储伪装成比特币脚本的monke jpegs。记住，比特币不是用来存储数据的，所以每当比特币开发人员不小心使其廉价且容易中继数据时，都应该将其视为一种漏洞。可以预期会修复它，或者至少为节点运行者提供对抗这种垃圾邮件的工具。

我们从这里该怎么办

这个故事中有趣的部分是，人们似乎对存储在比特币区块链上的图像附加了价值，他们愿意支付费用将其放入区块中，所以不具有意识形态的矿工和不关心比特币的健康和分散化的人都愿意支付费用并继续前进。

数据不应该享受折扣，如果人们想要存储数据，他们应该支付全价。他们应该只使用OP_RETURN和像opentimestamps或任何其他合理的协议一样的哈希来存储数据。

经过这个分析，Jb55认为这是一种相当糟糕的数据垃圾邮件漏洞，比特币开发人员应该致力于解决方案。像Luke这样真正关心网络的健康和分散化的理念开发者正在做这些工作，我很高兴看到这一点。