比特币核心开发者真的觉得BIP是对比特币的一个攻击？你别闹了！
比特币核心开发者：为什么认为铭文是针对比特币的一种攻击
又一位Bitcoin Core开发者站了出来！这次是我们喜闻乐见的Luke的支持者，反对铭文！
咦，铭文是一种对BTC的攻击？根据Bitcoin Core开发者兼Nostr开发者William Casarin在基于nostr的web应用habla.news上发表的文章，这种说法确实是存在的。
嘿，别急，让我来跟你好好解释如何把数据藏进比特币里吧。通常的方法是使用OP_RETURN操作码。比特币开发人员发现人们通过多签交易把数据存到utxo集里，比如比特币白皮书。但问题是，这个集不可修剪，随着时间推移会越来越大。于是有人提议用OP_RETURN输出代替，这样既可以修剪，又不会增加utxo的膨胀。
嗯，等等，我引用一下2014年3月Bitcoin Core v0.9.0发布说明的话给你听听：
关于OP_RETURN：关于0.9中的OP_RETURN功能和区块链中的数据，社区中存在一些困惑和误解。此更改并不是对在区块链中存储数据的认可。OP_RETURN 的更改创建了一个可证明可修剪的输出，以避免数据存储方案（其中一些已经部署）将任意数据（例如图像）存储为永远无法使用的 TX 输出，从而导致比特币的 UTXO 数据库膨胀。 在区块链中存储任意数据仍然是一个坏主意；将非货币数据存储在其他地方成本更低且效率更高。
你懂了吗？比特币核心人员主要是致力于保持系统的去中心化运行，使其能够在网络空间里安全畅通地传送数字货币。所以他们并不鼓励把比特币当成存储图片和数据的地方。为了避免一些愚蠢行为，比特币开发人员大度地让OP_RETURN交易保持了标准，这样它们就可以被同行和矿工转发了。
嘿，还有几个要注意的点：
- OP_RETURN交易只能推送40个字节（后来增加到80,83，我猜是为了支持更大的root merkle哈希，因为这是op_return唯一合理的用例）。
再补充一下，比特币还有一个名叫-datacarriersize的选项，限制了用户传递或挖矿的这些输出的字节数总和。
好了，让我们来看看为什么铭文在技术上可以看作是一种攻击吧！铭文通过在OP_IF块内使用OP_PUSH，将数据伪装成比特币脚本数据，绕过了数据载体大小的限制。Ordinas没有使用OP_RETURN，也不受数据载体大小限制的限制。因此，节点运行者和矿工目前对于他们所愿意传递并放入区块的数据总大小的控制是有限的。
铭文还巧妙地利用了segwit v1（witness discount，见证人折扣）和v2/taproot（no arbitrary script size limit，无任意脚本大小限制）中的功能。这些功能引入时有其原因和合理性的。
我们知道，见证人折扣的目的是降低之前执行许多输出所需的费用，有助于减小utxo集的大小。铭文正是利用了这个折扣来存储伪装成比特币脚本的一只猴子的jpeg。
记住，比特币不是用来存储数据的，所以只要比特币开发人员不小心让它变得便宜且易于传递数据，那就像是出现了一个漏洞。我期待着这个问题能够得到修复，或者至少为节点运行者们提供对抗这种垃圾邮件的工具。
接下来，我们该怎么办呢？这个故事有趣的一点是，人们对存储在比特币区块链上的图片赋予了价值，并愿意为了把它们放进区块里支付费用。哪怕只是一些毫无意识形态的矿工或者一些对比特币的健康和去中心化不那么关心的人，他们也乐意支付费用并不断前进。
不过，数据可不能打折啊！如果人们确实想存储数据，那他们应该付全价。而且他们还应该只使用op_return和哈希值，比如opentimestamps或其他任何合理的用来在比特币中存储数据的协议。
经过我的深度分析，我认为铭文是一种非常讨厌的数据垃圾邮件攻击，比特币开发人员应该着手解决这个问题。像Luke这样有思想的开发者实际上是非常关心比特币网络的健康和去中心化的，我知道这一点是多么让人高兴啊。
好了，朋友们，你们对于铭文的看法如何呢？欢迎在下方评论区分享你们的想法！
We will continue to update 算娘; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
