比特币铭文从问世以来就遭遇到了不少开发者的抵触，近期又一位Bitcoin Core开发者站出来，支持Luke，反对铭文。Bitcoin Core开发者兼Nostr开发者William Casarin在基于nostr的web应用habla.news上发文表示，铭文是对BTC的一种攻击。我反对Ordinals对比特币有利这一说法。我决定温习铭文工作原理的技术知识。我开始看到Luke关于它如何利用比特币反数据垃圾邮件机制中的漏洞的观点。
向比特币添加“数据”的标准方法是调用 OP_RETURN 操作码。比特币开发人员注意到人们通过大型多重签名交易将数据(如比特币白皮书)存储在utxo集里。问题是这个集是不可修剪的并且可能随着时间的推移而增长。另一方面，OP_RETURN 输出被证明是可修剪的，并且不会增加 utxo 的膨胀。
以下是 2014 年 3 月Bitcoin Core v0.9.0 发行说明的摘录，其中讨论了这一点：关于OP_RETURN：关于0.9中的OP_RETURN功能和区块链中的数据，社区中存在一些困惑和误解。此更改并不是对在区块链中存储数据的认可。OP_RETURN 的更改创建了一个可证明可修剪的输出，以避免数据存储方案(其中一些已经部署)将任意数据(例如图像)存储为永远无法使用的 TX 输出，从而导致比特币的 UTXO 数据库膨胀。 在区块链中存储任意数据仍然是一个坏主意;将非货币数据存储在其他地方成本更低且效率更高。
Bitcoin Core的大部分工作都集中在确保系统继续以去中心化的方式运行，以实现其预期目的，即使有人试图滥用它来存储数据等。Bitcoin Core一直不鼓励这种做法，因为它不是为存储图像和数据而设计的，而是为了在网络空间中移动数字货币而设计的。
为了帮助激励人们不做愚蠢的事情，OP_RETURN交易没有成为非标准的，以便它们可以被同行和矿工转发，但需要注意的是：
它们只能推送 40 个字节(后来增加到 80,83，我猜测是为了支持更大的 root merkle 哈希，因为这是 op_return 唯一合理的用例)
比特币还添加了一个名为 -datacarriersize 的选项，它限制了用户中继或挖掘的这些输出的字节总数。
铭文通过 OP_IF 块内的 OP_PUSH 将数据伪装为比特币脚本程序数据，从而绕过数据载体大小(datacarriersize )限制。Ordinas不使用 OP_RETURN 并且不受数据载体大小限制，因此节点运行者和矿工目前对他们希望中继并包含在区块中的数据的总大小的控制有限。Luke 的Bitcoin Core分叉有一些选项来对抗这种垃圾邮件，所以希望我们很快也能在Core中看到这一点。
铭文还利用了 segwit v1(witness discount，见证人折扣)和 v2/taproot(no arbitrary script size limit，无任意脚本大小限制)中的功能。这些功能中的每一个都有其引入的有趣且合理的原因。
见证人折扣的目的是使花费许多输出变得更便宜，这有助于减少utxo集的大小。铭文利用这一折扣来存储伪装成比特币脚本的猴子jpeg。记住，比特币不是用来存储数据的，所以只要比特币开发者不小心让它变得便宜且易于转发数据，那么这应该被视为一种漏洞。期望它能够得到修复，或者至少为节点运行者提供对抗这种垃圾邮件的工具。
这个故事的有趣之处在于，人们似乎对存储在比特币区块链上的图像赋予了价值，并且他们愿意支付费用以将其放入区块中，因此没有意识形态的矿工和不关心比特币健康和去中心化的人们很乐意收取或支付费用并继续前进。
数据不应该打折，如果人们想存储数据就应该支付全价。他们应该只使用 op_return 和哈希值，例如 opentimestamps 或任何其他合理的在比特币中存储数据的协议。
经过分析后，我认为这是一个非常糟糕的数据垃圾邮件攻击，比特币开发人员应该致力于解决方案。像Luke这样的意识形态开发者实际上关心比特币网络的健康和去中心化，我很高兴看到这一点。
| 正加财富网内容推荐 | ||
| OK交易所下载 | USDT钱包下载 | 比特币平台下载 |
| 新手交易教程 | 平台提币指南 | 挖矿方法讲解 |
