链下转移：比特币资产协议的演进之路

作者：Ben77

Starknet & Taproot Assets contributor\ 现专注在 Bitcoin 生态开发与研究

前言

基于 BTC 去做资产发行，一直都是一个热点话题。从最早在 2011 年出现的 Colored Coins 到近来大火的 Ordinal 协议，BTC 社区其实总能涌现出新的玩家和共识，但是能留下的寥寥无几。但随着野心勃勃的 Lightling Labs 宣布自己在 Taproot Assets 至上构建 Stable Coin 的计划，Tether 也宣布将选择 RGB 进行 USDT 在比特币一层的铸造。

这代表着曾经名噪一时的OmniLayer(Mastercoin)不再是BTC生态最大的玩家，客户端验证(CSV)资产协议由开始进入大家的视野，与传统的BTC资产协议的不同在于，它们还带上了为BTC扩容的属性。但是面对BTC生态如此繁多的资产协议，人们不禁要问，他们的差别在哪里，面对如此众多的资产协议，我们该如何去选择和并且从中找到自己的机会。

本文旨在引导读者回顾比特币历史上出现的各种资产协议，深入研究基于比特币的资产协议在可预见的未来发展的潜在轨迹。

染色币：Colored Coins

Colored Coins的想法最早由Yoni Assia，现eToro的CEO，在2012年3月27日的编写的一篇名为bitcoin 2.X (aka Colored bitcoin)文章提出。 文章认为比特币作为底层技术是完美的，就像HTTP是网络的基础一样。因此在复用BTC的基础上去设计了Colored Coins这个代币协议。

Yoni Assia希望通过这样的形式创建BTC2.0的经济-任何社区都可以通过这种方式来创建多种货币。这种将比特币作为底层技术用于清算交易和避免双重支付的方式在当时无疑于是非常大胆的想法。

Colored Coins作为一种基于比特币发行资产的协议，其做法就是将一定数量的比特币“上色”以表示这些资产。这些标记的比特币在功能上仍然是比特币，但它们同时也代表了另一个资产或价值。但是这样的想法该如何在比特币上实现呢？

2014 年 7 月 3 日，ChromaWay 开发了增强型基于填充订单的着色协议（EPOBC），该协议简化了开发人员制造彩色硬币的过程，这便是最早采用 Bitcoin Script 的OP_RETURN功能的协议。

最终实现的效果如下图所示：

这样的实现非常简洁，但是由此也带来了很多问题：

1. 同质化代币与最小绑定值

   在创世交易中为某个染色币绑定了1000 sat，则该染色币的最小分裂单位为1 sat。这意味着该资产或代币可以被切分或分配为最多1000份（但是仅为理论上的，为了防止粉尘攻击，比如当年的sat都定在546 SAT，后面到ordinal则是更高）。

2. 验证问题

   为了确定染色币的真实性和其所有权，需要从该资产的创世交易追踪验证到当前的UTXO。因此需要专门开发钱包与配套的全节点，甚至是浏览器。

3. 潜在的矿工审查风险

   因为ColoredTransaction的特征较为明显，即在output中写入了metadata信息，这给矿工审查带来了可能性。

染色币实际上是一种资产跟踪系统，它使用比特币的验证规则来追踪资产转移。不过，为了证明任何特定的输出（txout）代表某一特定资产，需要提供一整条从资产起源到现在的转移链。这意味着验证某笔交易的合法性可能需要很长的证明链。为了解决这个问题当初也是有人提出了OP_CHECKCOLORVERIFY来帮助在btc上直接对Colored Coins的交易正确性进行验证，但是该提案也并没有通过。

加密行业的第一个ICO：Mastercoin

Mastercoin 的最初概念由 J.R. Willett 提出。在2012年，他发布了一个名为"The Second Bitcoin Whitepaper"的白皮书，描述了在比特币的现有区块链上创建新的资产或代币的概念，这后来被称为“MasterCoin”。而再后来则改名为Omni Layer。

Mastercoin项目在2013年进行了一个初步的代币销售（今天我们称之为ICO或初始代币销售），并成功筹集了数百万美元，这被认为是历史上第一个ICO。Mastercoin最著名的应用则是Tether (USDT)，作为最知名的法币稳定币，最初是在Omni Layer上发行的。

其实Mastercoin的想法是要比Colored Coins出现得要早的，之所以在这里放在第二个去讲，是因为相对于Colored Coins来说，MasterCoin是一个相对来说更重的方案。MasterCoin建立了一个完整的节点层，从而提供了更为复杂的功能（如智能合约），Colored Coins则更加简单和直接，主要侧重于“染色”或标记比特币UTXO，以代表其他资产。

与Colored Coins最大的不同是，在链上Mastercoin只会去发布各种类型的交易行为，而不会记录相关的资产信息。在Mastercoin的节点中，会通过扫描比特币区块来维护一个状态模型的数据库在链下的节点中。

相对于Colored Coins来说，其能完成的逻辑要更加复杂。并且由于不在链上记录状态和进行验证，所以其交易之间可以不要求连续（持续染色）。

但为了实现Mastercoin的复杂逻辑，用户需要去相信节点中的链下数据库中的状态，或者自己允许Omni Layer节点来进行验证。

总结：

Mastercoin与Colored Coins最大的差异在于，其没有选择在链上维护协议所需的所有数据，而是通过寄生了BTC的共识系统，来实现了自己交易发布和排序，然后在链下数据库中维护状态。

据OmniBolt的相关提供的消息：Omni Layer正在向泰达提出新UBA(UTXO Based Asset)资产协议，会利用Taproot升级，把资产信息编入tapleaf，从而做到条件支付等功能。与此同时OmniBolt正在将Stark引入OmniLayer的闪电网络设施。

客户端验证(Client Side Validation)思想

如果我们要去了解客户端验证的概念，那么我们就要把时间拉回到Colored Coins和Mastercoin出现的第二年，那便是2013年。Peter Todd在这一年发布文章：Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation。虽然看文章名字上去和客户端验证没有关系，但是仔细阅读便可以发现这便是最早关于客户端验证的启蒙思想。

Peter Todd是比特币和密码学的早期研究者，一直在寻找一种使比特币工作方式更高效的方法。他基于时间戳的概念开发了一个更为复杂的客户端验证概念。此外，他还提出了“single use seal”的概念，这将在后面有所提及。

现在让我们顺着Peter Todd的思想，先要去了解BTC实际上解决了什么样的问题。在Peter todd看起来BTC总共解决了三个问题：

1. 证明的发布（Proof-of-publication）

   证明的发布本质是解决双花问题，比如Alice有一些比特币想要转给Bob，虽然通过签署了一笔交易转账给了Bob，所以Bob在物理上并不一定知道有这么一笔转账的存在。所以我们需要一个公共的地方进行交易的发布，并且每个人可以从中对交易进行查询。

2. 交易定序（Order consensus）

   在计算机系统，并不存在我们平常感受的物理时间。在分布式系统这个时间通常是分布式时钟lamport，这个时钟并不是为我们的物理时间提供度量，而是为我们的交易进行定序。

3. 交易验证（Validation）（可选项）

   BTC上的验证便是关于签名和BTC转账金额的验证。但是在这里，Peter Todd认为这个验证对于在BTC之上构建一个代币系统是非必要的，只是一个优化选项。

大家看到这里其实已经想到之前提到的Ominilayer，OminiLayer本身并没有把状态的计算和验证交给BTC，但是它同样复用了BTC安全性。Colored Coins则是把状态的追踪交给了BTC。这两者的存在已经证明了验证并不一定要发生在链上。

那么客户端验证如何有效验证交易？

首先来看看哪些东西是需要被验证的：

1. 状态（交易逻辑验证）

2. 输入TxIn是否有效（防止双花）

很容易可以发现在btc上发布的资产，每次交易都需要校验整个相关的交易的历史，才能确保引用的输入是没有被消费并且状态是正确的。这非常不合理，那么如何去改进呢？

Peter Todd认为，我们可以通过改变验证的焦点来简化这一过程。而不是确认一个输出没有被双重支出，这个方法重点放在了确认交易的输入已被发布，并且没有与其他输入冲突。通过对每个区块中的输入进行排序和使用Merkle树，可以更高效地进行这种验证，因为每次验证都只需要一小部分的数据，而不是该输入的整个链上的历史。

Peter Todd提出的commitment tree结构如下：

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn

但是我们该如何在链上存储这样一个commitment tree呢？所以在这里我们就可以引出一次性密封（single use seal）的概念了。

一次性密封 Single Use Seal

Single use seal是理解客户端验证的核心概念之一，这与实际世界中用于保护货运集装箱的物理、单次使用的密封相类似。Single use seal是一个独特的对象，可以确切地在一个消息上关闭一次。简言之，一次性密封是一个抽象的机制，用于防止双花。

对SealProtocol来说，有三个要素，两个动作。

基础要素：

• l： seal, 即是密封

• m： message, 消息

• w：witness, 见证人

基本操作：有两个基础操作：

• Close(l,m) → w：在消息m上关闭密封l，产生一个见证人w。

• Verify(l,w,m) → bool：验证密封l是否在消息m上被关闭。

single use seal的实现在安全性方面是无法被攻击者找到两个不同的消息m1和m2，并使得Verify函数对同一个密封返回true的。

首先一次性密封（Single-Use Seal）是一个概念，它确保某种资产或数据只被使用或锁定一次。在比特币的环境中，这通常意味着一个UTXO（未使用的交易输出）只能被消费一次。因此，比特币交易的输出可以被看作是一次性密封，而当这个输出被用作另一个交易的输入时，该密封就被“打破”或“使用”了。

对于在BTC上的CSV资产来说，比特币自己就充当了一次性密封的“见证人”（witness）。这是因为，为了验证一个比特币交易，节点必须检查交易的每个输入是否引用了一个有效且尚未花费的UTXO。如果一个交易试图双重花费一个已经被使用的UTXO，那么比特币的共识规则和全网的诚实节点会拒绝该交易。

能不能再简单一点？

single use seal 就是把任意一个区块链当作一个数据库，我们将某个消息的承诺通过某种方式存入这个数据库里，并且为它维护一个已消费或者待消费的状态。

是的，就是这么简单。

综上所述，客户端验证的资产有以下特点：

1. 链下数据存储：客户端验证的资产其交易历史、所有权和其他相关数据大多数都存储在链下。这大大减少了链上的数据存储需求，并有助于提高隐私。

2. 承诺机制：虽然资产数据存储在链外，但对这些数据的更改或转移会通过承诺（commitments）被记录到链上。这些承诺使得链上的交易能够引用链外的状态，从而确保链外数据的完整性和不可篡改性。

3. 链上见证者（不一定是BTC）：虽然大部分数据和验证都在链外，但通过嵌入到链上的承诺，客户端验证的资产仍然可以利用基础链的安全性（证明的发布，交易的排序）。

4. 验证工作在客户端完成：大部分验证工作都在用户设备上完成。这意味着不需要全网节点都参与验证每笔交易，只有涉及到的参与者需要验证交易的有效性。

对于使用客户端验证资产的人来说，还会有一点需要注意：

在链下交易和验证客户端验证的资产的时候，不仅要出示持有资产的私钥，也要同时出示对应资产的完整的merkel路径的证明。

客户端验证（CSV）的先行者：RGB

RGB的概念在2015后由社区中的知名人物Giacomo Zucco提出，由于以太坊的兴起和ICO开始泛滥，以及在ICO之前，许多人都尝试在比特币之外做一些事情，如Mastercoin和Colored Coins项目。

Giacomo Zucco对此表示失望。他认为这些项目都不如比特币，并且他认为之前在比特币上实现代币的方式都不恰当。在此过程中，他遇到了Peter Todd，对Peter todd在客户端验证(Client-Side-Validation)的想法开始着迷。便开始提出了RGB的想法。

RGB同此前的资产协议的最大的区别除了之前提到的客户端验证资产的那些特点，还增加了执行的VM来进行图灵完备的合约执行引擎。此外为了保证合约数据的安全性，还设计了Schema和Interface。Schema和以太坊的比较相似，声明合约的内容和功能，而Interface则负责具体功能的实现，与编程语言中的interface一样。

这些合约的schema负责在vm执行的时候限制没有超出预期的行为，比如RGB20和RGB21，分别负责同质化代币和非同质化代币在交易上的一些限制。

RGB 的承诺机制 PerdersenHash

从承诺机制来看，RGB采用了Perdersen哈希。它的优点在于可以承诺某个值而不用披露它。将 Pedersen 哈希用于构建 Merkle 树意味着你可以创建一个隐私保护的 Merkle 树，它可以隐藏其中的值。这种结构可用于某些特定的隐私保护协议中，如一些匿名加密货币项目。但是也许并不适用于CSV资产，在后面和Taproot Assets的对比里会提到。

RGB 的虚拟机设计 Simplicity → AluVM

RGB的目标不仅在于实现一个客户端验证的资产协议，更在于在扩展到图灵完备的虚拟机执行和合约编程进行扩展。在早期的RGB的设计中，它声称自己是用一个叫Simplicity的编程语言，该语言的特点是在执行表达式的时候会产生一个执行证明，并且能对其编写的合约更容易去做形式化验证（避免产生bug）。但是该语言的开发并不理想，最后陷入了困境。这最后直接导致了当年RGB整个协议难产。最后RGB开始使用一个叫AluVM，由Maxim开发的VM，目标是避免任何未定义的行为，这和最初的Simplicity类似。 新的AluVM据称在未来会使用一门叫Contractum的编程语言来替换当下使用的Rust。

RGB layer2扩容方向：闪电网络还是侧链？

客户端验证资产没有办法在链下保证安全的情况下连续交易的。因为客户端验证的资产还是依赖L1去进行交易发布和定序，所以在没有L2扩容方案的时候，其交易速度还是会受到其L1见证者的出块速度限制。这代表如果直接在比特币上进行RGB的交易，在严格的安全要求下，两笔相关的交易的时间需要最长间隔十分钟（BTC的出块时间）。毫无疑问，在大部分的时候这样的交易速度是难以接受的。

RGB与闪电网络

闪电网络的原理简单来说，就是交易的双方之间会在链下签一堆合同（承诺交易），用于保证交易双方中任何一方在违背合同的情况下，被侵害的一方能够把合同（承诺交易）递交到BTC进行结算，取回自己的资金并惩罚对方。也就是说闪电网络是通过协议和博弈的设计，保证在链下交易的安全性。

RGB可以通过设计适用于RGB自己的支付通道合同细则来构建自己的闪电网络设施，但闪电网络的复杂度极高，构建这套设施并不是容易的事。但相对于Lightnling labs已经在这个领域的多年耕耘，并且LND在市场上有着超过90%的占有率。

RGB 的侧链 Prime

LNP-BP作为当下RGB协议的维护者，Maxim在2023年6月发布了一篇提案叫Prime的客户端验证资产扩容方案，并在其中批评了现有的侧链和闪电网络扩容方案在开发方面太复杂。Maxim表示他认为除了Prime以外的扩展方式还有NUCLEUS多节点闪电通道和Ark/Enigma通道工厂,这两个方案都需要开发两年以上。但是Prime仅需要一年便可以完成。

Prime并非传统意义上的区块链设计，而是一个为客户端验证设计的模块化证明发布层，其由四个部分组成:

1. 时间戳服务 最快10秒最终确定一个交易序列。

2. 证明 通过PMT形式存储与区块头一同生产和发布。

3. 一次性密封 抽象的一次性密封协议，保证防双花即可。在比特币上实现，则是可以绑定到UTXO，与当下RGB设计类似。

4. 智能合约协议 分片合约-RGB（可替换）

从中其实可以看到，为了解决RGB交易确认时间的问题，Prime采用了一个时间戳服务来快速将链下的交易确认，并且将交易和ID装入区块中。并且于此同时可以把prime上的交易证明进一步通过PMT合并后再以类似checkpoint的方式锚定上BTC。

基于 Taproot 的 CSV 资产协议：Taproot Assets

Taproot Assets是基于Taproot的CSV资产协议，用于在比特币区块链上发行客户端验证的资产，这些资产可以通过闪电网络进行即时、大容量、低费用的交易。Taproot Assets 的核心是利用比特币网络的安全性和稳定性以及闪电网络的速度、可扩展性和低费用。该协议是由Lightnling labs的CTO roasbeef设计并开发，roasbeef可能是这个星球上唯一亲自主导过比特币客户端（BTCD）和闪电网络客户端（LND）的比特币研发，对BTC的理解极深。

Taproot交易只携带了资产脚本的根哈希，使得外部观察者难以辨识是否涉及Taproot Assets，因为哈希本身是通用的，能代表任意数据。随着Taproot升级，比特币获得了智能合约（TapScript）的能力。在此基础上，Taproot Assets的资产编码相当于创建了一个与ERC20或ERC721相似的代币定义。这样，比特币不仅拥有了资产定义的功能，还具备了智能合约的编写能力，从而为比特币打下了代币智能合约基础架构的雏形。

Taproot Assets编码结构如下：

同样作为CSV资产协议，Taproot Assets相对于RGB的设计更加简洁。并且最大利用了当下BTC生态的进展，比如Taproot升级，PSBT等。Taproot Assets在应用扩展性上同RGB最大的差异在于执行VM，Taproot Assets使用的是和BTC原生默认相同的TaprootScriptVM。近些年许多针对BTC的基础设施研究都是基于TapScript进行的，但受限于BTC的升级缓慢在短时间内得不到应用，可预见Taproot Assets未来会是这些新鲜想法的试验田。

Taproot Assets和RGB的差异在哪里？

1. 交易的校验与轻节点友好性

Taproot Assets由于sum tree的实现，验证效率和安全性高（仅通过持有证明便可以进行验证状态和进行交易，不需要遍历输入所有的交易历史）。RGB使用的pedersen承诺导致其无法有效去验证输入的有效性，导致RGB需要回溯输入的交易历史，交易衍生到后期将会是一个非常沉重的负担。Merkel sum的设计，也让Taproot Assets轻松实现了轻节点验证，这相对于以往在BTC之上的资产协议都不存在的。

2. 执行VM

Taproot Assets是顺应Taproot升级而生，其使用的TaprootScriptVM是比特币在Taproot升级后自带的脚本执行引擎，并且使用的vPSBT是BTC的PSBT的翻版，这代表一旦Taproot Assets的闪电通道机制开发完成，可以立刻复用所有当前LND的基础设施，还有以往Lightning labs的产品（LND在闪电网络目前的占有率在90%以上）。并且最近火热的BitVM提案都是基于TaprootScript的，理论上所有的这些改进最后都可以助力Taproot Assets。

但是对于RGB而言它的VM还有验证规则(SCHEMA)都是自成体系的，从某种程度上是一个相对封闭的小生态。基于RGB的构建只能在自己的生态里运转，其和比特币生态的关系都不如大家想象那般紧密。以Taproot升级的跟进举例，RGB和Taproot 升级唯一的关系便是把链上承诺数据编码到Witness的TapLeaf中。

3. 智能合约

当下RGB的实现设计里，合约和VM是一个被浓墨重彩的部分。但是在Taproot Assets中，暂时没有看到智能合约的身影。不过当下RGB在当下Global State的修改如何跟各个独立合约分片(UTXO)进行同步还没解释。且Pedersen承诺只能对资产总数进行保证，对于别的状态如何保证篡改被识别，目前看起来也没有更多解释。而对于Taproot Assets来讲，虽然设计简洁，但目前对于状态的存储也仅有资产余额，并没有更多状态，暂无法谈智能合约。不过据Lightning Labs透露，明年Taproot Assets将会在智能合约设计上发力。

4. 同步中心

从之前提到的在客户端验证的资产的基本原则中可以了解到，持有Proof和持有私钥同样重要，但是Proof一直在用户客户端则可能会是容易丢失的，那又该怎么办呢？在Taproot Assets中，我们可以通过universe来避免这样的问题。Universe是一个公开可审计的稀疏 Merkle shu，覆盖一个或多个资产。与普通的Taproot资产树不同，Universe不用来托管Taproot资产。相反，Universe承诺了一个或多个资产历史的子集。

在RGB之中负责这个部分的则是Storm，会把链下的证明数据通过p2p的方式进行同步存储，但是由于RGB的开发团队的历史原因，这些团队的证明格式目前都各不兼容。RGB生态团队DIBA目前则是表示会开发 carbonado 来解决这个问题，不过尚不清楚进度。

5. 工程实现

Taproot Assets所使用的所有lib都是久经考验的，因为Lightning labs有自己的比特币客户端（BTCD），闪电网络客户端（LND），以及大量wallet lib实现。反观RGB实现所用的lib大部分来自自己定义，从工业标准看RGB的实现尚处于实验室阶段。

浅谈 BTC 扩容的未来

讨论到这里，大家也就发现了客户端验证的资产协议已经脱离了协议的范畴，开始迈向了计算扩容方向。

很多人都说未来比特币将作为数字黄金去存在，而由其他链去打造应用生态。但是对此，我有不同的看法。就像在btc论坛上很多讨论都是关于各种山寨币(alt-coin)和它们短暂的生命。这些山寨币的快速的消亡，让曾经围绕它们的资本和努力都化为泡沫。我们已经有了比特币这样强大的共识基础，没有必要为了应用协议去构建新的L1。我们要做的就是如何将比特币这个最强的基础设施用好，从而构建一个更长期的去中心化的世界。

更少的链上计算，更多的链上验证

从应用设计来看，比特币很早选择了不是以链上计算为核心目标，而是以验证为主的设计哲学（Turing completeness and state for smart contract）。区块链本质是一个复制状态机，如果一个链的共识放在了链上计算，那么其实我们很难说最后让网络里所有的节点都重复这些计算是合理可扩展的做法。若是以验证为主，那么通过验证链下交易的有效性可能是最适合BTC扩容的方案。

验证发生在哪里？这很重要

对于在比特币之上的协议开发者而言，如何使用比特币做关键的验证，甚至说是把验证放在链下，如何设计安全方案，其实都是协议设计者自己的事情，不需要也不应该和链本身有所关联。那么如何实现验证，就会衍生出BTC不同的扩容方案。

那么基于验证实现的视角，我们有三个扩容的方向：

1. 验证发生在链上（OP-ZKP）

   如果在TaprootScriptVM直接去实现OP-ZKP，相当于让BTC本身加入ZKP验证的能力，从而再配合一些Covenant设计结算协议，就可以打造出能够继承BTC的安全性的Zk-Rollup扩容方案。但是不同于在以太坊上部署一个验证合约，BTC的升级本身就缓慢，再加入这样非通用并且可能需要后续升级的op-code注定是艰难的。

2. 验证发生在半链上 （BitVM）

   BitVM的设计注定了它不会是为了普通的交易逻辑服务，Robin linus也表明了BitVM的未来是做各个SideChain的自由跨链市场。之所以说BitVM的方案是发生在半链上，是因为大部分时候这些验证计算都不会在链上发生，而是说发生在链下。但是围绕BTC的Taproot去设计的重要原因是为了在必要的时刻也能够利用TapScriptVM进行计算验证，这样也是为了从理论上继承BTC的安全性。在这个过程中也同时产生了一个验证信任链条，比如n个验证人里只要有一个是诚实的就行，也就是Optimistic Rollups。

   BitVM在链上的开销巨大，但是能够使用ZK欺诈证明进行效率提升吗？答案是否定的，因为ZK欺诈证明的实现是建立在链上可以进行ZKP的验证的基础上，这就回到了OP-ZKP方案的困窘。

3. 验证发生在链下 （Client-Side-Validation, Lightning Network）

   验证完全发生在链下，那就是之前的讨论过这些CSV的资产协议还有闪电网络了。在之前讨论里可以看到在CSV的设计里，我们没有办法完全杜绝共谋篡改的发生，我们能做的就是利用密码学和协议设计让这种恶意共谋伤害的范围在可控范围内，使得这种行为无利可图。

   在链下验证的优点和缺点同样是非常明显，优点在于对链上的资源占用极少，扩容的潜力巨大。缺点则是几乎不可能去完全复用到BTC的安全性，这就对能进行的链下交易类型和交易方式有了极大的限制。并且链下验证也同时代表数据都在链下，由用户自行保管，这对软件执行环境安全性还有软件的稳定性上提出了更高的要求。

扩容演进的趋势

当下在以太坊流行的Layer2从范式上来讲，是通过Layer1去验证了Layer2的计算有效性，也就是把状态计算下推到了Layer2，但是验证还是保留在Layer1之上。在未来我们可以把验证计算同样下推到链下，进一步释放当下区块链基础设施的性能。

References

1. Assia, Y. (n.d.). Colored Bitcoin. Retrieved from <https://yoniassia.com/coloredbitcoin/>

2. CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from <https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/>

3. Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from <https://bitcoil.co.il/BitcoinX.pdf>

4. Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from <https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html>

5. Livera, S. (n.d.). Episode 501. Retrieved from <https://stephanlivera.com/episode/501/>

6. Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from <https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/>

7. Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from <https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d>

8. Burtey, N. (n.d.). Twitter Post. Retrieved from <https://twitter.com/nicolasburtey/status/1703705962664669225>

9. Burtey, N. (n.d.). Twitter Post. Retrieved from <https://x.com/nicolasburtey/status/1703710347889127585?s=20>

10. Bosworth, A. (n.d.). Twitter Post. Retrieved from <https://twitter.com/alexbosworth/status/1703423563288473769>

11. BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from <https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter>

12. Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from <https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin>

13. Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from <https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE>

14. Todd, P. (2016). OpenTimestamps Announcement. Retrieved from <https://petertodd.org/2016/opentimestamps-announcement>

15. Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from <https://bitcoinops.org/en/topics/client-side-validation/>

16. Todd, P. (2016). Commitments and Single-Use Seals. Retrieved from <https://petertodd.org/2016/commitments-and-single-use-seals>

17. Todd, P. (2014). Setting the Record: Proof of Publication. Retrieved from <https://petertodd.org/2014/setting-the-record-proof-of-publication>

18. Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from <https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality>

19. Linux Foundation. (2015). Mailing List Post Title (if applicable). Retrieved from <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html>

20. Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from <https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59>

21. Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from <https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/>

22. Linux Foundation. (2023). Mailing List Post Title (if applicable). Retrieved from <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html>

23. Salvatoshi. (n.d.). Twitter Profile. Retrieved from <https://twitter.com/salvatoshi>

24. Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from <https://merkle.fun/>

25. Muneeb. (n.d.). Twitter Post. Retrieved from <https://twitter.com/muneeb/status/1712853971948229042>

26. Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from <https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/>

27. Todd, P. (2013). Disentangling Crypto Coin Mining. Retrieved from <https://petertodd.org/2013/disentangling-crypto-coin-mining>