来源：巴比特作者：洒脱喜

译者按：如何将外部数据永久保存在比特币区块链上？对于这一问题，其实我们有不下10种答案，那在这些答案中，哪一种会是最佳的呢？论文作者通过研究发现，对于不同大小的数据，并不存在一种通用的最佳区块链数据嵌入方式。相反，根据不同的优先级以及要存储的数据量，选择不同的方法将是最优的。对于少量数据，使用OP_RETURN是一个可靠的选择。而对于较大量的数据，如果重点是考虑低成本，而不是考虑安全性，那么带有签名的数据删除法（Data Drop w/o Sig）可能是最好的选择。或者，你也可以采用带有签名的数据哈希法（Data Hash w/ Sig），其在数据完整性和有效成本之间提供了良好的平衡。

原文载于 ledgerjournal.org 期刊

作者：Andrew Sward,† Ivy Vecna,‡ Forrest Stonedahl§*

作者信息：†A. P. Sward (andrewsward@augustana.edu)是奥古斯塔纳学院应用数学助理教授

‡I. Vecna (ivyvecna15@augustana.edu)是奥古斯塔纳学院的一名本科生研究者

§F. Stonedahl (forreststonedahl@augustana.edu) 是奥古斯塔纳学院计算机科学分院的助理教授，

摘要：本论文提供了各类将任意数据嵌入比特币区块链的方法。文章描述了各类数据嵌入方法，以及一些鲜为人知的效率优化技术。我们对嵌入方法在效率、成本、数据重建便利性、持久性以及对比特币生态系统潜在负面影响这些方面，进行了深入的比较。

一、介绍

在比特币的创始区块诞生那一刻，其创始人中本聪在区块链中记录下了第一条永久信息，自那以来，比特币已经被用作一个自由言论的平台（1）（2）。 除了在全球范围内作为一种数字货币被交易之外，比特币还为用户提供了发布抗审查或无法被删除的信息能力，并将永久性地呈现给世界（只要比特币本身持续存在着）（3）。然而，关于比特币作为一种数据发布／存储平台的使用，是否是合适的这一问题，比特币社区内存在着分歧意见：

“使用比特币区块链存储与比特币支付无关的数据，是一个颇有争议的话题。很多开发人员认为这是一种滥用，并设法阻止这种行为。其他人则认为，这正是区块链技术强大能力的一种展示，他们还希望鼓励这种实验。” -Andreas Antonopoulos （4）

关于比特币可以做什么，以及应该做什么，每个人都有自己的想法。虽然我们倾向于支持数据嵌入可以是区块链合法且有价值应用的这一观点，但是本文的目的，并不是赞成（或反对）这种做法，而是列举有效的数据嵌入方式，并检查每种方法的优点和缺点。具体而言，我们将基于效率、成本、数据重构的便利性、持久性，以及对比特币生态系统的潜在负面影响，来比较这些数据嵌入方式。

我们相信，这项工作会引起几类读者的兴趣：

对于那些希望在区块链中存储数据的人，我们识别出在给定协议约束的情况下，哪些是实现数据存储优化的方法（并且最小化了相关成本）。

对于那些担心区块链被用于数据发布／存储的人来说，我们提供了目前可用方法的清晰概述，并解释了哪些方法减轻了对其他用户的负面影响。

对于未来的数据考古学者，我们提供了一个有价值的参考点，可以让后代发掘这些虚拟文物，否则这些虚拟文物将可能永远隐藏在二进制格式的区块链当中 （5）

二、 相关工作

众所周知的是，我们可以把外部数据存储到区块链上，并且有很多网站提供了对这些数据子集（6）（7）（8）的访问，并且其中有一些优秀的网站已经发现了以前存储的各种有趣历史文物（9）。尽管如此，关于数据可以（和已经）存储的各种不同方法，仍然存在着混乱以及错误信息。例如，最近有一本关于比特币的综合教科书，其中有这样一段内容：

“没有办法可以阻止人把任意数据写入到比特币区块链[sic]。其中一种可能的对策是只接受P2SH交易。这会使得写入任意数据的代价变得更高，但它仍然不能阻止数据写入这种行为，” （10）

第一个“不能防止任意数据嵌入区块链”的断言是正确的，因为目前我们并没有区分合法地址哈希和任意二进制数据的一般方法。然而，第二个说法却是错误的，因为对于存储大量任意数据而言，P2SH交易实际上提供了最便宜，也是最有效的方法（参见第5章）。

市场上，也有各类网站为用户提供了友好的数据发布工具（11）（12）。然而，这些工具目前使用的是P2FKH（Pay-to-Fake-Key-Hash）方法，而这种方法具有严重的缺点（详见第四章第2节内容），使得这些服务对用户而言效率低下，并且有害于比特币的基础设施。

虽然之前的一些研究工作，分析了比特币交易账本的图形结构和匿名性 （13）（14），但关于任意数据的发布与存储问题，目前学术界很少有过研究，只有为数不多的研究例子。

在2015年，Sleiman等人显然没有意识到，比特币用户已经将任意（ASCII和二进制）数据嵌入到了比特币的区块链中，他们天真地提出了一个协议，并使用交易货币量字段来编码数据，开发了用于将文本消息纳入区块链的软件（15）。结果这是一种非常低效的数据发布机制，每个交易输出只能存储最多8个小写字母。而最近，Bartoletti和Pompianu分析了附加到交易的元数据，这些交易使用了一种特定的数据嵌入方法（OP_RETURN，参见第四章第5节内容），从而在比特币协议之上构建协议层（例如，用于资产管理、公证等）（16）。在另一方面，Permacoin提出了构建比特币替代品的想法，它使用的是“可恢复性证明”机制，而不是“工作量证明机制”，通过这种机制，其允许用户将大量外部的任意数据存储到其交易账本上（17）。

三、 背景：比特币脚本语言

3.1. 标准脚本（ Standard Script）：用于创建交易的比特币堆栈脚本语言，我们简称为“脚本”。比特币交易包含了输入脚本和输出脚本。输入脚本是存储在区块链中先前交易的先前输出脚本（锁定脚本）的解决方案（解锁脚本）（18）。目前在比特币网络当中，共有5种用于交易的标准脚本类型（19）（20）。这些标准脚本类型包括P2PK（Pay-to-Public-Key）、P2PKH（Pay-to-Public-Key-Hash）、多重签名、P2SH（Pay- to-Script-Hash）以及OP_RETURN（详见附录B的脚本格式）第四章和第五章将演示如何使用这些脚本类型，将任意数据存储到比特币的区块链。

3.2. 方法：对于本论文中的历史方法分析，以及测试的每一种数据嵌入方法，我们使用了开源Java库BitcoinJ（21）。使用这一工具，我们遍历了比特币整个区块链，搜索那些不符合标准脚本类型的脚本，以及特定的脚本格式。我们还使用BitcoinJ构建了用于我们自己交易的脚本，并通过广播它们到比特币网络进行测试（通过Blockchain.info）（22）。你可以在附录D中找到构建脚本的示例代码。

3.3. 脚本和交易的技术限制：在撰写该论文时，一笔标准比特币交易被限定为100 KB大小，每个输入脚本被限制为1650 字节 （23）。并且任何被推至执行堆栈的单个元素都被限制为520字节。在脚本执行之后，堆栈必须精确地包含一个非错误的元素（24）。输入脚本可能不会包含除OP_PUSHDATA之外的任何OP码（除非在P2SH特殊赎回脚本部分内）。一笔P2PKH交易的最小输出值（最小非粉尘－见附录A中的定义）目前为546聪。

与这些规则相背离的交易，会被认为是非标准的，大多数矿工不会接受这种交易（25）。

3.4. 标准脚本执行：上面对脚本的大多数限制，都是通过Bitcoin Core源代码中被称为isStandard的方法执行的（26）。这些限制被纳入Bitcoin Core客户端，是有各种原因的，其中包括性能考虑以及防止交易延展性问题（参见第六章第2节内容）。然而，这严重限制了可写入的输入和输出脚本。使用P2SH交易的输入脚本，是当前比特币脚本语言使用时能够提供某些灵活性的唯一选择。这种灵活性允许对金融交易进行更复杂的逻辑操作，并且还允许使用各种各样的数据嵌入机制。我们将首先解释四种相对简单的非P2SH方法（见第四章），然后解释相对复杂的基于P2SH的方法（见第五章）。

四. 不涉及P2SH的数据嵌入方法

4.1. Coinbase：coinbase数据是一笔生成交易的输入内容。coinbase数据是任意的，最多可以达到100字节。（27）（28）coinbase数据是由矿工自行决定的，其通常被矿工用于嵌入ASCII编码字符串，声明其矿池的名称或其它短消息。矿工还会使用coinbase数据来对比特币协议的各种提议更改进行投票表决。而在未来版本的比特币协议当中，其中部分coinbase数据可能会被开发者所征用。虽然这个字段是作为一种在区块链中存储任意数据的一种方式，但它仅面向矿工，而不是针对一般的比特币用户。因此，为了文章的全面性，本论文将其包含在内，但在后面的内容中不会再次提及它。

4.2. P2FKH：这是一种非常常见，并且具有争议的数据嵌入方法，其利用了标准P2PKH脚本，将数据存储在输出脚本的 字段当中，同时用于“烧毁”非粉尘数量的比特币。我们称其为P2FKH（Pay-to- Fake-Key-Hash）。用户不具有将他们存储的数据进行哈希操作的公钥。因此，这些交易输出永远无法被使用。然而，因为它们是有效的未花费交易输出（UTXO，详见附录A），矿工并不知道哈希是否对应于某人拥有的真正公钥，矿工必须跟踪这些UTXO（永远）。由P2FKH方法提供的存储是每个输出20 字节，但是很多输出可以包含在单笔交易当中。这种方法已经被用于比特币区块链的文本（29）、图片（见图1），以及mp3文件存储（30）。这也是诸如Apertus.io.这类工具目前所使用的方法。

图片1: 这张纳尔逊曼德拉的JPEG图像，存储于2013年12月7日，其通过P2FKH的方式存储于多笔交易，存储的区块高度在273,536，其数据大小为14,400字节（31）。

4.3. P2FK：数据也可以通过P2FK（伪公钥）的方式进行存储，而不是伪公钥哈希（fake public key hash）。一个未压缩的公钥是65字节（32），并且整个脚本有3个更小的OP码，使得这比P2FKH数据存储方式更有效。然而，作为一种数据存储方式，它似乎并没有被社区所广泛使用。一个可能的原因是，节点检测伪（未压缩）公钥相对容易，比特币开发者（或矿工）将来可以关闭掉这种方法（33）。使用一个伪压缩公钥（33字节）存储数据能够解决这个问题，并且仍然比P2FKH提供的数据效率更高。然而，这种方法也遇到了创建不可扩展UTXO的问题。

4.4. 由虚假地址所引起的问题，包括流行的P2FKH以及P2FK方法都是有问题的，原因有几个：

(1) 它们的存储方法是低效的，会导致比需求更多的UTXO，尤其是P2FKH。 (2)矿工必须永久跟踪每一个通过这类方式创建的不可使用的UTXO； (3)这些方法会不可挽回地“燃烧”比特币。P2FKH和P2FK都要求用户向每个虚假地址发送少量比特币（大于或等于最小粉尘交易值）。 (4)在区块链中存储的任意数据，会使得整个账本大小不断“膨胀”；

前三个问题，可以通过使用改进的数据存储方法来解决。而第四个反对意见则可适用于任何数据插入方法，因为区块链注定是会变得更大的，区块会不断产生，交易会不断增长，这与交易本身代表着什么并没有什么关系。所存储的数据价值，是否值得使用比特币网络的资源，这个是社区将继续讨论的问题。不管数据存储的应用是什么，比特币依旧会面临可扩展问题，而开发人员们已试图解决这个问题（例如隔离见证segwit（34），Peter Todd提出的Merkle Mountain Range协议，其可以避免存储完整的UTXO集 （35））。

表1:在P2FKH交易中存储ASCII信息所燃烧的比特币（Ƀ）

表1展示了，截至2017年6月7日，使用P2FKH方法所烧毁的比特币数量（估算）。具体来说，我们聚集了所有P2PKH UTXO的余额（其地址从未被用作输入脚本），并且密钥哈希（key hash ）包含来自可打印ASCII字符集的18（或更多）个连续字节、加标签、换行符以及空字符 (‘\x00’) ，这些字符可能用作正文数据的填充。（36）

4.5. OP_RETURN：OP_RETURN标准脚本，是作为越来越多用户所用P2FKH存储数据（或元数据）方式的一种应对方式（37）。OP_RETURN允许每笔交易中可包含少量数据，创建一种可证明的不可花费UTXO，从而矿工就不需要跟踪它，并且不需要燃烧非粉尘价值的比特币。

在一笔比特币交易当中，可能会有很多的输出，但它们当中只有一个输出可以是OP_RETURN（38），OP_RETURN当前在每笔交易中只能存储80字节的内容。这个限制会随着时间的推移而波动（见Bartoletti和Pompianu讨论的有关OP_RETURN的历史 （16））。而想要使用多个OP_RETURN，我们就需要相应多的交易（39）。这些交易的顺序是通过去中心化的比特币网络来负责的，因此很难去控制。总的来说，这种方法适合用于嵌入少量的数据（或交易原数据），其对于大量数据的存储而言是不合适的。一些社区成员还对使用OP_RETURN存储数据的健壮性表示担心，这是因为不可花费的UTXO是可以被节点修剪掉的，并且可能不会被那么多的节点永久存储或传播（40）。

4.6. P2FMS：P2FMS是另一种常用的区块链数据插入法，其全称为 (Pay-to-Fake-Multisig) ，它是1-of-2或1-of-3的多重签名脚本（41），其带有一个真实的公钥，以及1-2个包含任意数据的假公钥（42）。因为这些交易是可花费的，所以用户可以避免让UTXO膨胀。为了获得最低的开销成本，人们会使用（真实的）压缩公钥，并使用两个假的未压缩公钥（每个65字节）存储数据。此方法会把数据保存在UTXO集中，直到用户决定花费这些输出（使用唯一的真实公钥）。多个P2FMS输出可以存储在单笔交易当中， 并始终使用相同的真实公钥，这使得数据重构简单明了。

然而，包含单个OP_CHECKMULTISIG的交易必须大于400字节；具体来说，每个sigop的默认要求是20字节（43），OP_CHECKMULTISIG的一个实例计算为20 sigop（44），这一限制使得赎回这些UTXO是不经济的：花费这些UTXO的费用成本，将远大于通常发送给它们的最小非粉尘交易值（45）。因此，不考虑UTXO膨胀问题的用户，可以简单地使用所以3个公钥字段来存储具有燃烧效应的任意数据。

五. 使用P2SH的数据插入方法

5.1. P2FSH：类似于P2FKH，P2FSH（Pay-to-Fake-Script-Hash）方法只将数据存储为假哈希。P2FSH需要比P2FKH少两个OP码（使其稍有效率优势），但它仍然会创建一个不可花费的UTXO。在第五章的其余部分，我们将主要谈论在输入脚本中存储数据的方法，这些脚本花费了一个P2SH输出，输出脚本则不予讨论。

5.2. P2SH交易的两大阶段：P2SH有两个阶段，创建UTXO，以及花费UTXO，为了创建一个P2SH UTXO，用户首先要创建一个赎回脚本，然后将HASH160算法应用于该脚本，（46）这个输出脚本然后：

OP_HASH160 

为了使用这个UTXO，用户会创建一个输入脚本（引用上面的UTXO），其由赎回脚本本身所组成（作为单个堆栈元素，其限制为520字节），在脚本操作序列之前，这将使赎回脚本在执行之后仅为“true”。（47）有两种数据嵌入方法：要么将任意数据存储在赎回脚本当中，要么将任意数据存储在赎回脚本之前的输入脚本的部分当中。例如，用户可以简单地创建一个赎回脚本，该脚本包含一个OP_PUSHDATA2（3字节），后面跟着517字节的数据元素（48）。由于除了OP_0之外的任何堆栈元素都会被评估为“true”，这个脚本将成功赎回UTXO。

然而，由于赎回脚本存在520字节的限制，将大量数据存储在赎回脚本之前的输入脚本的部分当中，会更为有效（请参见图6）。在附录C中我们会完整讨论这些方法。下面的基于P2SH的方法，自2014年6月以来，已被用于区块链的数据存储（49）。

5.3. 数据删除方法：数据删除方法将数据推送到堆栈上，并在脚本执行期间，从堆栈中删除数据，其通常会使用OP DROP操作。参考下面的赎回脚本：OP_DROP ... OP_DROP （50） 前面的输入脚本操作，然后是。存储的数据必须划分成块，每个块最多为520字节。其中签名是71-73字节，赎回脚本是37字节，那么在考虑推送数据的OP码之后，任意数据可用的空间就只有1529字节。回想一下，输入脚本受限于1650字节的输入大小限制（参见第三章第3节），但这些输入可以与单笔交易链接到一起（最高可达每笔交易100 KB的大小限制），并以近乎连续且易于重构的格式存储大量数据（更多关于重构的细节参见第八章）。该方法已被用于在区块链单笔交易中存储相对较大的图形文件（参加图2）。

作为赎回脚本的一部分，我们引入了一个压缩的 ) 阻止双重支付攻击（参见第六章第1节）。这种数据嵌入方法，提供了最低的成本，它避免使用了签名和密钥，以便将更多的数据打包到每个交易输入当中，而其代价是潜在的敌对篡改问题。然而，即使使用了签名，恶意者也可以使用数据删除法（参见第六章第2节）来执行在线攻击篡改数据存储。下面，我们会进一步讨论最大化存储容量，与确保交易安全性和数据完整性之间的权衡。

图2， 2017年4月5日，有人使用带有签名的数据删除法（Data Drop w/ Sig，具有OP_DROPs赎回脚本的多个P2SH输入），将Mr. Burns的JPEG图像存入了比特币区块链的单笔交易当中（没有“燃烧”比特币）。图像大小：34600字节 （51）

5.4. 数据哈希方法：数据哈希法是更为复杂的一种区块链数据嵌入方法（52）。区块链历史上最大的输入脚本就是这种脚本类型的一个例子；该交易是在2014年11月27日被纳入区块链的，发起者并没有公布身份（53）（54），这笔交易潜入了一张模仿西联广告的比特币图片（见图3）。与数据删除法类似，这一方法处理赎回脚本之前的输入脚本，重复了

OP_HASH160 

然后，通过输入脚本将每个数据元素推送到堆栈上，重复这三个命令。这个脚本不仅仅将每个数据元素从堆栈中删除，还使用哈希值来验证每个数据块没有被篡改。由于哈希被存储在赎回脚本中，并且这个赎回脚本的哈希被记录在来第一阶段的UTXO中，所以，即使该交易的输入未签名，也没有其他数据可被替换为花费这个UTXO的输入脚本。但是，为了防止恶意者在竞争交易中重新排序输入或纳入输入子集，使用者仍然需要对每个输入进行签名（通过在输入脚本的开头插入 ）。这些安全问题将在下一章中进行讨论。

图3. 这个JPEG图像作为GZIP存档文件存储在比特币区块链的单个P2SH 输出的输入脚本当中。（压缩）大小：9,265字节。这个输入脚本是区块链至今出现最大的输入脚本（55）。

六. 安全性和数据完整性

6.1. 狙击UTXO：我们将一笔交易未签名的输入重新分配到一个带有不同输出（由狙击者创建并同时广播）的新交易，以劫持这些输入所代表的资金，这个过程我们称之为狙击（sniping）（56）。这些双重支付尝试当中，只有其一可被纳入区块链。而签名的设计，就是为了防止狙击，因为它们可以禁止恶意者对交易的签名部分进行任何更改（这样做将需要生成一个新的有效签名，恶意者没有用户的密钥就无法完成这一步）。然而，当用户为输入脚本创建签名时，输出脚本是安全的，但输入脚本本身却并不安全。（57）

没有签名的赎回脚本因此会是脆弱的。如果多次使用这样的脚本，它可能会与它的哈希相关联，并且使用该哈希的UTXO，可以被提供相应赎回脚本的任何人所使用。我们可以在赎回脚本中包含一个唯一的元素，以便每次使用的是不同的赎回脚本哈希（58）。然而，这些交易，仍然可以通过复杂的机器人进行实时狙击。

6.2. 交易延展性：我们所定义的交易延展性，是指对正在广播（在区块接受之前）的一笔交易进行任何更改。交易延展性是困扰比特币多年的一个问题，Bitcoin Core开发团队通过多种方式已尝试解决这一问题。这一问题对一般用户而言，实际威胁其实很少，但对数据发布者而言却是个恼人的问题，这是一个值得讨论的潜在严重问题（59）。

当一笔新交易被广播到P2P比特币网络时，它会从一个节点传递到另一个节点，节点会负责验证它，并将它存储到可能交易的交易存储器中，然后再纳入一个区块。而恶意节点在接受到一笔交易后，创建该交易的修改版本，然后再传递给网络中的其它节点。这些变化可能与改变一个PUSHDATA OP码一样无害（60），但更有害的变化可能是使用数据删除法更改存储的任意数据。只要脚本本身仍可导致有效执行，修改后的交易将具有一个新的交易ID，并以这种修改的形式被纳入区块链当中。由于带有签名的数据删除方法防止了狙击的发生，所以目前看，它并不会是恶意代理节点的目标（61）。但是，数据删除方法并不包含防止网络上代理节点修改用户数据的措施，即使对每个输入都进行了签名。与之相反的是，数据哈希法确保了数据完整性，因为在执行赎回脚本期间，其会检查每个数据元素的哈希。尽管不包含签名的数据哈希交易可以很容易地被狙击，狙击者仍必须包含确切地未修改数据作为输入。然而，对于多个（无签名）输入的数据生成，狙击者可以重新排列输入，或者只花费其中一些输入（不使用其它输入），从而导致数据以非预期的顺序存储在区块链当中。仅仅从经济利益为目的的恶意方，可以通过为每个（未签名的）P2SH输入只分配最小值的非粉尘比特币来实现狙击目的，这使得狙击者有效地支付更多的费用（存储你想要的数据），然后他们会通过重新将输出导入到他们自己的地址，从而实现盈利目的（62）。因此，在使用多个输出时，能够保证数据完整性的唯一方法，就是带有签名的数据哈希法。

而那些更简单的数据插入方法（P2FKH, P2FK, P2FMS, P2FSH, OP_RETURN）都不存在交易延展性或狙击问题，因为这些方法的数据是通过签名的输出存储的（63）。

表二. 基于P2SH的数据嵌入方法总结（单个输入）

* 用于这些计算的完整脚本，参见附录C **如果遭遇狙击，交易中的多个输入可重新排序，即使每个输入中的数据都不能更改。

表二从安全性和数据容量这两个点，总结了两种（带签名和不带签名）基于P2SH的数据嵌入方法的情况。尽管带有签名的数据哈希方法提供了这些方法中最小的数据容量，但其保证数据完整性的好处，可能会大于其效率损失。

七. 效率和成本比较

首先，我们探讨一下在UTXO中使用伪地址致使UTXO集膨胀的效率问题（如第四章第4节中所讨论的），这影响了比特币生态系统的可扩展性：

1、P2FKH和P2FSH都是非常浪费的，每个不可花费的UTXO只提供20字节的数据。 2、P2FK也是非常浪费的，尽管使用未压缩的密钥，目前其可使每个不可花费的UTXO提供65字节的数据存储（64）。 3、当前允许的P2FMS形式（3个地址都是伪地址），可使每个不可花费的UTXO最多存储多达195字节的数据，而具有1个真实密钥的P2FMS交易是可花费的，但目前没有经济效益来挽回最小非粉尘值比特币。 4、OP_RETURN并不会使UTXO集变得膨胀，因为它是可证明不可花费的，并且节点可能会删除它。 5、两种形式的（数据删除和数据哈希）将数据存储在输入脚本的P2SH方法，并不会增加UTXO集，因为所有创建的TXO（交易输出）都会得到赎回。

接下来，我们还考虑了两种额外的效率问题：

（1）总数据量（即包括数据开销），需要被加入到区块链中，为了存储指定数量的任意数据（图4和表3所示）。这涉及了可扩展性问题，并且会受到那些存储完整区块链副本的人的关注。

（2）比特币总消耗量，使用当前最低（20聪／字节）的费用，以及一次交易所需的最小非粉尘燃烧费率（用于存储指定数量的任意数据）（如图5和表3所示）（65），就是总共消耗掉的比特币。这种方式，对于那些希望在区块链中进行廉价数据存储的人而言，是有意义的。

表3. 对于20聪／字节方法（最大数据存储以及成本）的总结

* 数据单位（字节） **成本单位（比特币）

*** 数据存储的效率

如图4和图5所示，OP_RETURN对于少量数据的存储（最多80字节）而言，它是最为有效的选择。而对于中等数量的数据（80-800字节之间）而言，P2FMS是最具成本效益的选项，其提供的最小数据开销约为10 KB。而对于大量数据存储（超过800字节），带有签名的数据删除法（Data Drop w/o Sig）会是最佳的选择，它需要至少10 KB以上的数据开销。

在输入脚本（数据删除和数据哈希）中存储数据的P2SH方法，具有较高的固定开销（因为需要一笔初始交易来建立第二笔交易所赎回的UTXO），对于处理大量数据而言，这种方法比P2FK 和P2FMS提供了具有竞争力的数据开销水平，并且成本要低得多（因为它们避免了每个UTXO的燃烧成本）。

示例；对于一个50 KB的文件而言，最具成本效益的安全方法（Data Hash w/ Sig）大约会花费0.012 BTC,其相比P2FKH（≈ 0.03 BTC）能够节省61%的成本。按当前的汇率（1 BTC ≈ 6300美元）计算，将其发布到比特币区块链上，大约会花费75.6美元。

八、数据重构

8.1. 涉及燃烧的方法：所有依靠伪密钥或伪哈希的方法，对于重构而言都是繁琐的。对于P2FKH，每个输出包含了20字节要检索的数据，并且很多有序输出可用于存储连续的数据集。为了重构数据，需要从每个输出脚本中的密钥或哈希中提取数据（66）。必须小心避免交易中表示“更改”地址的任何P2PKH输出；数据输出通常用它们最小非粉尘值来标记。一笔交易的输出数量，似乎没有明确限制（67）。在100 KB大小限制下，P2FKH最多能够存储58,680字节数据，而总交易的数据大小为99,983字节。而较之更大的文件，则需要在不同的交易之间分隔存储，并随后链接在一起（在区块链本身或通过外部信息）（68）。这使得存储在区块链中的数据集的全自动重构工作，变得更加困难。对于P2FMS，重构还意味着避免在伪密钥之间的推送数据OP码。

8.2. 不涉及燃烧的方法：对于数据删除和数据哈希法，数据是以相同的方式存储在输入脚本当中的。假设不考虑延展性问题，数据将以和广播数据相同的顺序存储在单笔交易当中（数据开销高达100 KB），从而实现存储最大96,060字节的文件（69）。一个OP_RETURN输出可以用于元数据，例如文件的名称，或者用于文件大于100 KB的下一个数据块的TX ID（70）。为了便于检索，一笔交易可以纳入一个单独的P2FKH输出，该输出对存储的数据文件的哈希进行支付，这类似于Cryptograffiti所采用的方法（12）。此方法，允许具有此哈希的任何人，使用通用的区块链搜索工具查找存储数据的交易。图6显示了一个输入脚本的解剖结构。

作为重构的参考点，请仔细思考以下交易，其通过带有签名的数据哈希法（Data Hash w/o Sigs）存储了一张JPEG图像：

TX ID: 033d185d1a04c4bd6de9bb23985f8c15aa46234206ad29101c31f4b33f1a0e49 Block: 474586

赎回脚本数据很容易地被识别为每个输入的最后一个数据元素。这个JPEG数据先于赎回脚本，每次三个数据元素。第二个到最后一个输入只包含在赎回脚本之前的两个数据元素。最终的输入并不包含图像数据，它只是用于支付费用。

图4. 对于小数据（左）和大数据（右），所需的总数据 vs 存储数据大小，以及单笔交易中可能达到的最大值；

图5. 对于小数据（左）和大数据（右），所需的货币成本 vs. 存储数据大小，以及单笔交易中可能的最大大小。此图假设一笔交易

的费用是20聪／字节，以及P2FMS法 1100聪的燃烧费用，以及其他方法需要燃烧的546聪；

图6. 对一笔带有签名的数据哈希（Data Hash w/ Sig）交易，进行最大大小输入（保持1461字节的任意数据）的剖析。它由输入脚本（上半部分）和赎回脚本（小半部分）组成。单元格内的数字，标记每个字段的字节数。红色字段表示OP码，深蓝色字段表示插入的任意数据块（以及该数据的哈希），而浅绿色字段表示与签名相关的数据（省略w/o Sig变体）。

九、结论

综合考察现有方法的优缺点，我们可以发现，对于不同大小的数据，并不存在一种通用的最佳数据嵌入方式。相反，根据不同的优先级以及要存储的数据量，选择不同的方法将是最优的。对于少量数据，使用OP_RETURN是一个可靠的选择，其也可能是最接近数据发布标准的存在。而对于较大量的数据，如果重点是考虑低成本，而不是考虑安全性，那么带有签名的数据删除法（Data Drop w/o Sig）可能是最好的选择。或者，你也可以采用带有签名的数据哈希法（Data Hash w/ Sig），其在数据完整性和有效的成本之间提供了良好的平衡。然而，社区中有很多人认为，区块链并不适合存储大量数据，它应该用于存储文件的短哈希（即时间戳存在证明）而不是完整的文档。社区中的其他人则采取了强硬的自由市场立场，并认为，如果用户愿意承担数据插入成本，他们可以按自己的意愿使用这类技术。本文的目的，不在于对这些观点进行价值判断，而是鼓励对处于危险中的技术和经济问题进行知情讨论。从务实的层面上看，考虑近来比特币的汇率，即使是最有效的数据插入方法，要在比特币区块链上存储一个大文件也可能是非常昂贵的，除非这个插入数据对发布者具有重大且持有的意义。

令人惊讶的是，P2FKH（它似乎是一些数据发布工具使用的主要方法）在几乎所有的方面都表现不佳：它导致了最严重的UTXO膨胀问题，它需要最大的数据开销，并且花费了最多的成本（11）（12）。我们有几个假设，可以解释为什么它会是流行的（也可能不合理）：

（1）它是最简单的实现方法之一；

（2）大多数人都不知道存在更复杂的方法（比如使用输入脚本来存储数据）（72）

（3）工具制造商担心在比特币的未来版本中，开发者可能会禁止更复杂的方法，这会破坏兼容性；

（4）用户担心，那些不创建不可花费UTXO的任何数据都不会足够持久，因为它们可能在将来会被修剪掉；

最后一个假设是最有趣的。一方面，只要比特币存在着，就肯定有节点将始终保存完整账本（包括输入脚本），以便对过去的交易进行完整归档，而且能够验证从一开始所有区块的哈希。另一方面，UTXO本身可能不能免于修剪，由于未来可能会出现新的密码数据结构来存储UTXO状态，而无需直接存储 UTXO数据的可能性（35）。然而，这很可能会充当矿工／节点的缓存优化，而包括非常旧的UTXO完整记录仍会被存档在磁盘上。

作为最后的附加说明，我们试图对当前和过去的主要数据插入技术进行了一个全面回顾，而本文中所包含的知识和方法都是基于脚本协议的，而脚本协议会不断变化，因此本文中所讨论的一些方案，可能在将来变得不可用。例如，隔离见证（segwit）BIP对于利用输入脚本实现长期数据存储的可行性影响，会是未来测试和研究的一个重要问题（34）。然而，即使未来Bitcoin Core的更改禁用或启用了与数据存储相关的新旧功能，记录迄今所使用的方法，也会具有重要的学术价值，并可能构成比特币在未来的数据发布方法以及其他密码技术的基石。

鸣谢

我们要感谢Bitcoin Core开发团队成员迅速响应我们的问题。我们也感谢Daniel Zwiener提供的一些有趣谈话。这项研究是由奥古斯塔纳新教师科研资助计划资助的。

作者贡献

APS指导了这个项目，编写了大量初始手稿，并创建了图表（37.5%的工作量），IV编写了嵌入方法的代码，并负责搜索了区块链先前存储的数据，以及编辑了手稿（37.5%的工作量）。FS咨询了技术问题，并负责创建图表，细化手稿（25%的工作量）。

附录A:常用术语列表

我们列出了本论文中使用的一些常用的定义和缩写。 • 粉尘交易（Dust）：如果用于花费一笔交易输出（由输出的大小和支出所需的输入大小决定）的费用，会达到这一输出值的1/3以上，那么这个输出值，我们称之为粉粉尘。具有粉尘输出值的交易，被认为是非标准的；• 最小非粉尘交易（Min Non-Dust）：最小非粉尘值是一个可以输出的最小值，它不会使输出被标记为粉尘。目前P2PKH的最小输出值是546聪。这一最小阈值会根据使用的脚本而改变；• 可证明不可花费（Provably Unspendable）：一个OP_RETURN UTXO就是可证明不可花费的，这意味着比特币协议已经将其标记为不可花费。因此，它不需要包含在未来可能被花费的UTXO集中。与之相对应的是，一些交易输出实际上是不可花费的，因为它们的脚本没有已经解决方案。花费一个P2FKH输出需要生成与公钥对应的私钥，这在数学上是不可能的。

• 赎回脚本（Redeem Script）：一个被哈希操作的脚本，这个哈希被用作一个Pay- to-Script-Hash交易的输出。当用户希望花费所创建的输出时，赎回脚本和其它所需的任何输入就会被提供。这些输入和赎回脚本本身会被执行，并且返回“true”值时才会使交易有效；• 可狙击（Snipeable）：在这篇论文中，通过创建带有不同输出的新交易，重新安排一笔未确认交易的未签名输入过程，从而实现劫持这些输入所代表资金的过程，我们称之为狙击。如果一笔带有未签名输入的交易是可重新分配的，我们称之为可狙击交易。• 交易延展性（Transaction Malleability）：交易延展性是指在不使交易无效的情况下，对交易进行任何更改的能力。交易延展性通常只会带来带来一些微不足道的不便，但上述描述的一些数据存储方法可能会遭受恶意攻击者的影响，他们可能会更改用户要存储的部分或全部数据。• UTXO（未花费交易输出）：每一个（非coinbase）输入引用先前的UTXO，来花费与该UTXO相关的币。我们可以把UTXO集看作是存储比特币的地方，并可能作为未来比特币交易的来源。

附录 B: 标准交易脚本

(1) Pay-to-Public-Key (P2PK):

输出 (locking) 脚本:输入 (unlocking) 脚本:

(2) Pay-to-Public-Key-Hash (P2PKH):

输出脚本: OP_DUP OP_HASH160 输入脚本:

(3) 多重签名 (a.k.a. “bare multisig”, or “multisig output”):

输出脚本: M 输入脚本: OP_0

(4) Pay-to-Script-Hash (P2SH):

输出脚本: OP_HASH160 输入脚本:

(5) OP RETURN:

输出脚本: OP_RETURN (最多 80 字节) (该输出永远都不会被花费, 因此没有相应的输入／解锁脚本)

附录C: P2SH 存储 - 完整脚本

(1) 没有签名的数据删除法（Data Drop w/o Sig）: 输入脚本:

(2) 有签名的数据删除法（Data Drop w/ Sig）: 输入脚本:

(3) 没有签名的数据哈希法（Data Hash w/o Sig）: 输入脚本:

赎回脚本: OP_HASH160

(4) 有签名的数据哈希法（Data Hash w/ Sig）: 输入脚本:

赎回脚本: OP_HASH160

OP_EQUALVERIFY

附录D: BitcoinJ示例代码

下面的代码将遍历整个比特币区块链，直至blk文件 END_BLOCK_NUM（假设这些区块链文件存储在 ../../Blockchain当中），并创建一个输出文件，其中包含了非P2PK（及P2PKH）的所有输出脚本。这个例子将处理前51个blk文件（编号为0-50）

// This source code adapted from:// - blockchain/BriefLogFormatter.init;
final int END_BLOCK_NUM = 50;
// output file to print non-P2PK, non-P2PKH scriptsPrintStream out = new PrintStream(new File("../../output/output0-"
+END_BLOCK_NUM+".csv"));
// Arm the blockchain file loader. NetworkParameters np = new MainNetParams;
Context context = Context.getOrCreate(np); List
for(inti=0; i
}
// allows us to iterate through blocksBlockFileLoaderbfl = new BlockFileLoader(np, blockChainFiles);
intblockNum = 0;// iterate through all blocks
for (Block block : bfl) {
List
// iterate through all transactions for (Transaction tx : txs) {
intoutputNum = 0;for (TransactionOutput output : tx.getOutputs) { try { // some transaction outputs cause issues
// for example, output script OP_1
Script script = output.getScriptPubKey;// segment script into OP codes List
// ignore P2PK
if (chunks.size == 2&&chunks.get(0).isPushData&& (chunks.get(0).data.length == 65|| chunks.get(0).data.length == 33) &&chunks.get(1).opcode == ScriptOpCodes.OP_CHECKSIG) {
// ignore
// ignore P2PKH} else if (chunks.size == 5
&&chunks.get(0).opcode == ScriptOpCodes.OP_DUP &&chunks.get(1).opcode == ScriptOpCodes.OP_HASH160 &&chunks.get(2).isPushData &&chunks.get(2).data.length == 20 &&chunks.get(3).opcode == ScriptOpCodes.OP_EQUALVERIFY &&chunks.get(4).opcode == ScriptOpCodes.OP_CHECKSIG) {
// ignore
// print other scripts to file } else {
out.println(blockNum + "," + txNum + "," + outputNum + ","
+ output.getValue + "," + script); }
outputNum++;} catch(Exception ex){
// print exceptions to consoleSystem.out.println(blockNum + "," + txNum + "," + outputNum
+ "," + output.getValue + ",EXCEPTION: " + ex);
} }
txNum++;} blockNum++; }

我们可以修改它，将其用于搜索其它类型的脚本、可印ASCII等。

创建交易

创建一个P2PKH脚本（以支付给对应密钥地址）的代码：

public static Script createP2PKHScript(ECKey key) {ScriptBuilder script = new ScriptBuilder;script.addChunk(new ScriptChunk(ScriptOpCodes.OP_DUP, null)); script.addChunk(new ScriptChunk(ScriptOpCodes.OP_HASH160, null)); script.data(key.getPubKeyHash);script.addChunk(new ScriptChunk(ScriptOpCodes.OP_EQUALVERIFY, null));script.addChunk(new ScriptChunk(ScriptOpCodes.OP_CHECKSIG, null));return script.build; }

通过使用其他编码，我们可以很容易地编写其他脚本。元素应该通过ScriptBuilder.data(byte[] data) 方法以及上面的PubKeyHash，作为一个推送数据元素被添加。然后，使用Transaction.addOutput(Coin value, Script script)的实例方法，通过这种方式创建的输出脚本，可以被添加到BitcoinJ交易当中。

向一笔交易添加输入并不是繁琐的，因为他们（通常）必须要被签名。鉴于给定的交易哈希以及要花费的UTXO索引，以及要被赎回的脚本，下面的代码将向一笔花费UTXO的交易添加一个输入。注意，必须在所有输入被添加后生成签名。

public static TransactionInputaddInputToTransaction(Transaction tx, long index, String hash, Script scriptPubKey) {return tx.addInput(Sha256Hash.wrap(hash), index, scriptPubKey); }

签名一个输入的代码如下，其中tx是指交易，input是指要被签名的输入，key是指用于签名输入的密钥，script是指要被花费的输出脚本，index 是指交易中输入的索引；

public static void signInput(Transaction tx, TransactionInput input, ECKey key, Script script, long index) {ScriptBuildersigScript = new ScriptBuilder; Sha256Hash hash = tx.hashForSignature(index, script,Transaction.SigHash.ALL, false);ECKey.ECDSASignatureecSig = key.sign(hash); TransactionSignaturetxSig = new TransactionSignature(ecSig,Transaction.SigHash.ALL, false);sigScript.data(0, txSig.encodeToBitcoin);// Add any additional data/pubkeys/etc. to the SigScript here.Script scriptWithSig = sigScript.build; input.setScriptSig(scriptWithSig);}

其他必要的数据（例如赎回P2PKH脚本的公钥或存储在区块链中的任意数据），应该像 txSig一样，作为推送数据元素添加到sigScript。

注释与参考文献

1 “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” TX ID: 4a5e1e4baab89f3a32518a8831bc87f618f76673e2cc77ab2127b7afdeda33b Block: 0.

2 Nakamoto, S. “Bitcoin: A peer-to-peer electronic cash system.” (2008) Bitcoin.org (accessed July 2017) .

3 Be aware that anything published in the Blockchain is publicly available and can be accessed by anyone, and it cannot be retroactively altered or removed. For this reason, some use cases may want to store encrypted data or just a hash, rather than plaintext data.

4 Antonopoulos, A. M. Mastering Bitcoin: Unlocking Digital Cryptocurrencies. Sebastopol, CA: O’Reilly Media 133 (2014).

5 Textual data is fairly easy to recover, regardless of the insertion method, by searching for ASCII-printable strings, e.g. using the Unix strings command on the .BLK files. However, binary data files (images, sounds, compressed files, etc.) are difficult to locate without understanding the structure of the transactions and scripts that were used to store the data.

6 Majakivi, A. (a.k.a. Anduck). Bitcoinstrings.com (accessed July 2017) .

7 Coin Sciences Ltd. Coin secrets (beta) (accessed July 2017) .

8 HugPuddle Team. Bitfossil (accessed July 2017) .

9 Shirriff, K. “Hidden surprises in the Bitcoin blockchain and how they are stored: Nelson Mandela, Wikileaks, photos, and Python software.” Ken Shirriff’s blog (accessed July 2017) .

10 Narayanan, A., Bonneau, J., Felten, E., Miller, A., Goldfeder, S. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton: Princeton University Press 217-218 (2016).

11 HugPuddle Team, embii, The AtomSea. Apertus (accessed July 2017) .

12 Erstu, E. (a.k.a. 1Hyena). Cryptograffiti.info v0.90 (accessed July 2017) .

13 Ron, D., Shamir, A. “Quantitative Analysis of the Full Bitcoin Transaction Graph.” In A. Sadeghi (Ed.), Financial Cryptography and Data Security, 17th International Conference, FC 2013, Okinawa, Japan, April 1-5, 2013, Revised Selected Papers, New York: Springer 6-24 (2013) .

14 Reid, F., Harrigan, M. “An analysis of anonymity in the bitcoin system.” In Y. Altschuler et al. (Eds.) Security and Privacy in Social Networks. New York: Springer 197–223 (2013) df.

15 Sleiman, M. D., Lauf, A. P., Yampolskiy, R. “Bitcoin message: Data insertion on a proof-of-work cryptocurrency system.” In 2015 International Conference on Cyberworlds, IEEE 332–336 (2015) . ledgerjournal.org ISSN 2379-5980 (online) 15 DOI 10.5915/LEDGER.2018.101 LEDGER VOL 3 (2018) 1−23

16 Bartoletti, M., Pompianu, L. “An Analysis of Bitcoin OP_RETURN Metadata.” arXiv preprint (2017). .

17 Miller, A., Juels, A., Shi, E., Parno, B., Katz, J. “Permacoin: Repurposing bitcoin work for data preservation.” In Security and Privacy (SP), 2014 IEEE Symposium on, 475–490 (IEEE, 2014).

18 Technically, transactions may also reference other transactions that have not yet been confirmed in a block but are residing in the mempool.

19 Antonopoulos, A. M. Mastering Bitcoin: Unlocking Digital Cryptocurrencies. Sebastopol, CA: O’Reilly Media 128-9 (2014).

20 This has changed over time. Check the current Bitcoin Core client to see what is currently allowed as a valid transaction script.

21 bitcoinj Java Library (accessed July 2017) .

22 Blockchain.info (accessed July 2017) .

23 Chosen because it can handle 15 compressed keys for a multisig transaction as a P2SH, as of Bitcoin Core 0.9.3.

24 Bitcoin Core Development Team. “Make Transactions with Extra Data in their ScriptSig’s Non- Standard.” commit message (2012) bce469dbfa52333331a5d15c6545.

25 This list of rules is not comprehensive and is subject to change over time. We list only the rules that directly affect data storage methods discussed in this manuscript.

26 Ironically, due to Bitcoin’s decentralized approach, the isStandard method is anything but standard, as miners and nodes on the Bitcoin network can adhere to all, some, or none of these “standard” script restrictions, or even create their own standards to enforce. Moreover, recently the isStandard method has been explicitly moved to a configuration file to be more easily modifiable by users. This means that innocuous-looking scripts that could result in valid execution may never be propagated by a large portion of the network while other strange-looking scripts might be propagated without issue.

27 BIP 34 adds height as the first item in the coinbase: .

28 Antonopoulos, A. M. Mastering Bitcoin: Unlocking Digital Cryptocurrencies. Sebastopol, CA: O’Reilly Media 187-8 (2014).

29 TX ID: 930a2114cdaa86e1fac46d15c74e81c09eee1d4150ff9d48e76cb0697d8e1d72 Block: 138725.

30 An MP3 of Spock saying: “Live long and prosper,” spread across multiple transactions inside of block number 345858.

31 There is some extra data in the first and last transaction that is not essential to reconstruct the image.

32 The OP code for pushing 65 bytes is 41 which corresponds to ‘A’ in ASCII, and thus if this method is used for text publication, the first byte should probably be reserved for a newline (or other non-printable ASCII character) so that the popular text extraction scripts do not extract the extraneous ‘A’ as part of your text.

33 Nodes could check the x and y coordinates of the public key to ensure they are valid points on the elliptic curve. ledgerjournal.org ISSN 2379-5980 (online) 16 DOI 10.5915/LEDGER.2018.101 LEDGER VOL 3 (2018) 1−23

34 Segregated Witness (segwit) Bitcoin Improvement Proposal. blob/master/bip-0141.mediawiki.

35 Todd, P. “Making UTXO set growth irrelevant with low-latency delayed txo commitments” - May/012715.html.

36 This table overstates the value of BTC burned to store textual data, since a significant portion (≈ 58 BTC) was paid to the known burn address of all 0s, which likely relates to some proof-of-burn mechanics rather than data storage. However, the table also underestimates both the value burned and the number of transactions that store all data, since binary data (JPEG images, MP3 files, etc.), which tends to be much larger than text, is not accounted for. As of July 2017, there were approximately 52 million total UTXOs (see Lopp, J. “Unspent transaction output set graph,” Statoshi dashboard (Accessed July 2017) ), meaning that unspendable ASCII/whitespace/null P2FKH UTXOs comprise about 0.25%. Obtaining an exact accounting of unspendable UTXOs (that store data) is impossible, since arbitrary binary data (especially compressed/encrypted data) can be indistinguishable from legitimate hashes.

37 Antonopoulos, A. M. Mastering Bitcoin: Unlocking Digital Cryptocurrencies. Sebastopol, CA: O’Reilly Media 133 (2014).

38 a1470c257c78233bda3/src/policy/policy.cpp#L152. 39 Using more transactions necessitates more inputs and possibly outputs, increasing fees. 40 See comments in: . 41 More than 3 public keys in a “bare” multisig output script are marked non-standard; higher (e.g. 1-of-12) multisigs are generally done using P2SH.

42 TX ID: a1e537ac06869cf63845ee1fc1a267c5b3bd1db3ac36e6a21fa4ffe20a941b2a Block: 351746.

43 .

44 .

45 Even assuming a very low 5 satoshi/byte fee and TX size of 400, a 2000 satoshi fee is nearly quadruple the size of the current min non-dust value.

46 HASH160 is a shorthand for RIPEMD(SHA256(Redeem Script)).

47 BIP 62 requires that the stack contain precisely one non-false value after script execution.

48 TX ID: afe9034d3afb9d7d8db064b7944d42b30d650d333819cdbe0132ed71febb9725 Block: 475205.

49 TX ID: d771f31ad04904564da77c1106cde85d06cd641cf2977ffa36f0dd03e89eef4f Block: 307594.

50 For utmost efficiency, OP_2DROP should be used to drop two data elements from the stack at a time.

51 TX ID: 94e319d09fc236fb9d7a24e60af8f47ed41ca3cc01e9950c925d806153ed8aa3 Block: 460435.

52 Sometimes colloquially referred to as the “Western Union” or “WU” method. See Fig. 3.

53 TX ID: 200f3f6f8a91ae438d1924e5cedca98cea7f0197b9eba11343948b5621ca19ed Block Number: 331804. ledgerjournal.org ISSN 2379-5980 (online) 17 DOI 10.5915/LEDGER.2018.101 LEDGER VOL 3 (2018) 1−23

54 This script format resembles the approach used to store textual data in Peter Todd’s publish-text.py (see above, n.58), but Todd denied authorship of this transaction, which predates the publication of his Python script by about 5 months.

55 Likely to remain so, given the current limit on the size of inputs is now only 1650 bytes.

56 This behavior has been observed in the wild.

57 The signature is based on a modified copy of the transaction with empty input scripts. See for details.

58 Todd, P. publish-text.py (accessed July 2017) - bitcoinlib/blob/master/examples/publish-text.py.

59 A user’s transaction may be modified in a minor way that does not affect the transaction’s functionality but does alter the TX hash, which can make it more difficult for wallet software to track its status.

60 Shirriff, K. “Bitcoin transaction malleability: looking at the bytes.” Ken Shirriff’ s blog (accessed July 2017) .

61 However, this could change if adoption becomes widespread and/or if transaction malleability continues to be a problem in the future.

62 Note: an adversary may have much stronger motives for mangling the data publication, depending on the data in question. Also, automated sniping scripts may be programmed to act in an economically rational way, but it seems risky to count on this.

63 Technically, the standard malleability concerns apply regarding altering TX IDs via nonfunctional changes, but the signature protects the integrity of data fields within output scripts.

64 Although note that if future versions of Bitcoin choose to crack down on data storage using this mechanism, it would be necessary to format your data as a “valid” compressed public key (33 bytes long, starting with 02 or 03).

65 Fees vary as a result of competition between transactions within the mempool. A transaction fee of 20 satoshis/byte currently appears sufficient to ensure the transaction is included in a block eventually, although in times of heavy traffic it could take a long time (we have witnessed wait times of up to one week with this fee rate). Higher fees increase your transaction’s priority, which could be necessary for publication of time- sensitive data.

66 Do not confuse the PubKeyHash (as bytes of data) with the Base58Check encoded Bitcoin Address.

67 The largest number of outputs within a single transaction in the Blockchain we found is 13,107. TX ID: dd9f6bbf80ab36b722ca95d93268667a3ea6938288e0d4cf0e7d2e28a7a91ab3 Block: 391204. This transaction exceeds the 100 KB transaction size limit currently imposed by isStandard.

68 Multiple transactions all broadcast simultaneously could end up inside a block in any order, or be separated by blocks.

69 63.7% more data than P2FKH.

70 Beware of malleability issues, even a change of a single pushdata OP code will change the TX ID.

71 In fact, it can be used to store small amounts of text using any standard wallet software, with a relatively simple conversion to convert ASCII data into a Bitcoin address.

72 We hope this paper will help to remedy this.