比特币数据输出（OP_RETURN 算子）

比特币的分发和带时间戳的账户机制（又名区块链）的潜在应用远远超出支付。 许多开发者试图充分发挥交易脚本语言的安全性和可恢复性优势，将其应用到电子公证服务、证券认证和智能协议等领域。 比特币脚本语言的早期使用主要包括在区块链上创建交易输出。 例如，为文件记录电子指纹，任何人都可以通过它来证明文件在特定日期存在。

使用比特币区块链存储与比特币支付无关的数据是一个有争议的话题。 许多开发人员认为它是滥用行为并试图阻止它。 其他开发人员试图支持它，将其视为区块链技术力量的证明。 反对非支付相关应用程序的开发人员认为，这样做会导致“区块链膨胀”，因为所有区块链节点都会以磁盘存储空间为代价来负担存储此类数据的负担。 更严重的是，此类交易仅使用比特币地址作为20字节的自由组合，进而会产生无法用于交易的UTXO。 由于比特币地址只是作为数据使用，与私钥不匹配，因此UTXO不能用于交易挣比特币的软件，属于伪支付行为。 这样的做法会增加内存中的UTXO，不能用于交易的数据无法移除，因此比特币节点将永久负责这些数据，这无疑是昂贵的。

在 Bitcoin Core 客户端 0.9 版本中，最终通过采用 OP_Return 运算符实现了妥协。 OP_Return 允许开发者在交易输出中添加 40 字节的非交易数据。 然后，与伪交易 UTXO 不同，OP_Return 创建了一个明确可审查的非交易输出，不需要存储在 UTXO 集中。 OP_Return 输出记录在区块链上，它们会消耗磁盘空间并增加区块链的大小，但它们不存储在 UTXO 集合中，因此不会扩展 UTXO 内存，并且不会以昂贵的消耗为代价的内存，整个节点不堪重负。

OP_RETURN 脚本样式：

OP_RETURN

“数据”部分限制在40字节以内挣比特币的软件，多以哈希方式呈现，如32字节的SHA256算法输出。 许多应用程序将其作为前缀以帮助识别。 例如，电子司法服务的证明材料使用8字节前缀“DOCPROOF”，在十六进制中，对应的ASCII码为44f4350524f4f46。

请记住，OP_RETURN 不涉及解锁脚本可用于支付的特性，OP_RETURN 无法花费其输出中锁定的资金，因此无需记录在具有潜在成本的 UTXO 集中，因此 OP_RETURN 实际上是无成本的。 OP_RETURN 通常是数量为 0 的比特币输出，因为与该输出对应的任何比特币都已永久消失。 如果 OP_RETURN 遇到脚本验证软件，它会立即使验证脚本和标记交易的行为无效。 如果您碰巧将 OP_RETURN 的输出用作另一笔交易的输入，则该交易无效。

一个标准交易（由 isStandard() 函数传递）只能有一个 OP_RETURN 输出。 但是单个 OP_RETURN 输出可以与任何类型的输出事务组合。

5.7.5 P2SH（支付脚本哈希）

P2SH 作为一种新的、强大的交易类型于 2012 年推出，可大大简化复杂的交易脚本。 为了进一步说明P2SH的必要性，我们先来看一个实际的例子。

在第 1 章中，我们介绍了位于迪拜的电子产品进口商 Mohammed。 Mohammed 的公司采用比特币多重签名作为其公司会计账簿的要求。 多重签名脚本是比特币高级脚本最常见的应用之一，是具有相当影响力的脚本。 对于所有客户付款（即应收账款），Mohammed 的公司都需要多重签名交易。 基于多重签名机制，客户的任何支付都需要至少两个签名才能解锁，一个来自穆罕默德，另一个来自他的合作伙伴或具有备用密钥的代理人。 这样的多重签名机制可以为公司治理提供便捷的管控，也可以有效防止盗窃、盗用和丢失。

最后的脚本很长：

2 5 OP_CHECKMULTISIG

多重签名虽然很强大，但是使用起来还是有些不方便。 基于之前的脚本，Mohammed必须在客户付款之前将脚本发送给每个客户，并且每个客户还必须使用可以生成客户交易脚本的特殊比特币钱包软件，并且每个客户都必须学习如何使用脚本来完成交易. 此外，由于脚本中可能包含极长的公钥，最终交易脚本的长度可能是原始交易脚本的 5 倍之多。 额外长度的脚本将成为客户的成本负担。 最后，一个长长的交易脚本会被记录在所有节点RAM的UTXO集合中，直到资金被花完。 所有这些都使得在真实交易中实现复杂的输出脚本变得困难。

P2SH 就是为了解决这个实际问题而引入的，它旨在让复杂脚本的使用变得像直接向比特币地址支付一样简单。 在 P2SH 支付中，复杂的锁定脚本被电子指纹所取代，电子指纹是加密哈希。 当交易尝试支付 UTXO 时，要解锁支付脚本，它必须包含与哈希匹配的脚本。 P2SH 的思想是支付匹配该哈希的脚本，稍后将在输出支付时渲染。

在 P2SH 交易中，锁定脚本被哈希替代，哈希指的是赎回脚本。 因为它是在赎回时出现在系统中的，而不是锁定脚本模式。 表 5-4 列出了非 P2SH 脚本，表 5-5 列出了 P2SH 脚本。

表 5-4 没有 P2SH 的复杂脚本

锁定脚本

2 公钥 1 公钥 2 公钥 3 公钥 4 公钥 5 5 OP_CHECKMULTISIG

解锁脚本

信号 1 信号 2

表 5-5 P2SH 复杂脚本

赎回

脚本 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG

锁定脚本

OP_HASH160 OP_EQUAL

解锁脚本

Sig1 Sig2 赎回脚本

正如您在表中看到的，在 P2SH 中有一个复杂的条件脚本来花费（赎回脚本），这在锁定脚本中是不存在的。 相反，在锁定脚本中，只有哈希出现，赎回脚本稍后作为解锁脚本的一部分出现，当输出被支付时。

再看Mohammed公司的例子，复杂的多重签名脚本和对应的P2SH脚本。

首先，Mohammed 对所有客户订单使用多重签名脚本：

2 5 OP_CHECKMULTISIG

如果占位符被替换为实际的公钥（520 字节，以 04 开头），您将看到的脚本会很长：

204C16B8698A9ABF84250A7C3EA7EE-DEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DA-DA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1EC-ED3C68D446BCAB69AC0A7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG

整个脚本可以用只有 20 字节的密码哈希代替，先用 SH256 哈希，然后用 RIPEMD160 哈希。 20字节的脚本是：

54c557e07dde5bb6cb791c7a540e0a4796f5e97

P2SH 交易使用锁定脚本将输出与哈希相关联，而不是与特别长的前导脚本相关联。 使用的锁定脚本是：

OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL

如您所见，此脚本比之前的长脚本短得多。 这个 P2SH 不是“支付给 5 个多重签名脚本”，而是等同于“用这个哈希支付给脚本”。 客户只需要在向 Mohammed 付款时将这个非常短的锁定脚本包含在他们的付款说明中。 当Mohammed想要花费这个UTXO时，只要附上原始的赎回脚本（用UTXO进行哈希锁定）和必要的解锁签名即可，例如：

这两个脚本分两步组合。 首先，将 redeem 脚本与 lock 脚本进行比较，看它是否与哈希匹配：

OP_HASH160 OP_EQUAL

如果赎回脚本与哈希匹配，则执行解锁脚本以释放赎回脚本：

2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG