Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols - Discoco Labs

Author: @Ben77

Starknet & Taproot Assets contributor
Now focusing on developing Bitcoin ecosystem

Foreword

Issuing assets based on BTC has always been a hot topic. From the earliest Colored Coins in 2011 to the recently popular Ordinal protocol, the BTC community has consistently been able to come up with new players and consensus, but few have stuck around. However, Lightning Labs has unveiled ambitious plans to develop stablecoins based on Taproot Assets. Tether also announced that it would utilize RGB protocol for minting USDT on Bitcoin's layer 1.

This means that the once-famous OmniLayer (formerly Mastercoin) is no longer the biggest player in the BTC ecosystem. And client side validation (CSV) assets protocols are beginning to enter everyone's vision. These protocols not only maintain the integrity of traditional Bitcoin asset protocols but also enhance scalability. However, an array of asset protocols within the Bitcoin ecosystem, raises pertinent questions: How do they differ from one another, and how should one navigate and seize opportunities within this landscape?

This article aims to guide readers through a comprehensive review of the various asset protocols that have emerged in the history of Bitcoin. Furthermore, it seeks to delve into the potential trajectories for the evolution of Bitcoin-based asset protocols in the foreseeable future.

Colored Coins

The Colored Coins concept was first articulated by Yoni Assia, now the CEO of eToro, in his seminal article "bitcoin 2.X (aka Colored bitcoin)" on March 27, 2012. The article posited that Bitcoin's underlying technology was as foundational and flawless as HTTP is for the internet. Therefore, the Colored Coins token protocol was designed on top of BTC.

Yoni Assia envisioned the creation of BTC 2.0 economies through this innovation, enabling any community to generate multiple currencies in this manner. Utilizing Bitcoin's underlying technology for transaction settlement and prevention of double-spending was, at the time, a pioneering idea.

Colored Coins is a protocol designed for issuing assets on the Bitcoin blockchain. It operates by "coloring" a specific fraction of bitcoins to signify other assets. These marked Bitcoins still retain their original functionality, but they also represent another asset or value. The pressing question, however, was how this idea could materialize on the Bitcoin network.

On July 3, 2014, ChromaWay made a significant stride by developing the Enhanced Colored Coins Order-based Protocol (EPOBC), which greatly simplified the creation process of colored coins for developers. This was the inaugural protocol to employ the OP_RETURN function of Bitcoin Script.

The result looked like this:

Such an implementation is very concise, but it also brings many problems:

Fungibility and minimum binding value issue By binding 1000 sats in the genesis transaction for a colored coin, the minimum unit of that colored coin becomes 1 sat. This means the asset or token can theoretically be divided into a maximum of 1000 units (but in practice it is lower to prevent dust attacks. For example, the minimum satoshi value was once set at 546 SATs, and for Ordinals, it's even higher).
Validation challenges In order to determine the authenticity and ownership of a colored coin, its transaction history needs to be traced back and validated from the genesis transaction to the current UTXO. Therefore, dedicated wallets, full nodes and even scanner need to be developed.
Potential miner censorship risk ColoredTransaction has distinct characteristics, such as writing metadata in the output, this brings the possibility of miner censorship.

Colored Coins are essentially an asset tracking system that uses Bitcoin's validation rules to track asset transfers. However, in order to prove any specific output (txout) represents a particular asset, you need to provide the entire chain of transfers from the origin of the asset. This means validating the validity of a transaction may require a long proof chain. To address this, proposals like OP_CHECKCOLORVERIFY were made to help validate Colored Coin transactions directly on BTC, but the proposal was not adopted.

The First ICO in Crypto: Mastercoin

The concept of Mastercoin was initially proposed by J.R. Willett. In 2012, he published a whitepaper titled "The Second Bitcoin Whitepaper," which outlined the idea of creating new assets or tokens on top of the existing Bitcoin blockchain. This concept eventually came to be known as "MasterCoin," which was later renamed to Omni Layer.

In 2013, the Mastercoin project conducted an early version of what we today refer to as an ICO (Initial Coin Offering), successfully raising millions of dollars. This is considered to be the first ICO in history. One of Mastercoin's most notable applications is Tether (USDT), a well-known fiat-collateralized stablecoin, which was initially issued on the Omni Layer.

In fact, the idea of Mastercoin predated Colored Coins. The reason we're discussing it second is that, compared to Colored Coins, MasterCoin is a relatively more comprehensive solution. MasterCoin established a full node layer, offering more complex functionalities such as smart contracts. In contrast, Colored Coins is simpler and more direct, primarily focusing on "coloring" or marking Bitcoin UTXOs to represent other assets.

The key difference between the two is that on the blockchain, Mastercoin only records various types of transaction behaviors and doesn't store related asset information. In the nodes for Mastercoin, a database of the state model is maintained by scanning Bitcoin blocks, and this database resides in the nodes off the blockchain.

Compared to Colored Coins, Mastercoin can execute more complex logic. Also, because it doesn't record or verify states on the blockchain, its transactions don't need to be consecutive (continuously colored).

However, to implement Mastercoin's complex logic, users need to trust the state maintained in the off-chain database within the nodes or run their own Omni Layer nodes to perform verifications.

In summary:

The main difference between Mastercoin and Colored Coins is that Mastercoin doesn't maintain all the data required for the protocol on the blockchain. Instead, it piggybacks on Bitcoin's consensus system to manage its own transaction publishing and ordering, and then it maintains the state in an off-chain database.

According to information provided by OmniBolt: Omni Layer is proposing a new UBA (UTXO Based Asset) asset protocol to Tether, which will utilize the Taproot upgrade. This protocol will embed asset information into tapleaf, enabling functions like conditional payments. At the same time, OmniBolt is working on integrating Stark into the Omni Layer's Lightning Network infrastructure.

The Concept of Client Side Validation

If we want to understand the concept of Client Side Validation (CSV), we need to go back to the year following the emergence of Colored Coins and Mastercoin, which is 2013. In that year, Peter Todd, an early Bitcoin and cryptography researcher, released an article titled "Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation." Although the title doesn't explicitly mention Client Side Validation, a careful reading reveals that this is one of the earliest pieces of writing to introduce the concept.

Peter Todd has been seeking ways to make Bitcoin's operation more efficient. He developed a more complex concept of client-side validation based on the idea of timestamps. Additionally, he introduced the concept of a "single use seal," which will be mentioned later on.

To follow Peter Todd's thinking, we first need to understand what problem Bitcoin actually solves. According to Peter Todd, Bitcoin addresses three issues:

Proof-of-publication: The essence of proof-of-publication is to solve the double-spending problem. For example, if Alice wants to transfer some bitcoins to Bob, although she has signed a transaction to transfer to Bob, Bob may not physically know that such a transaction exists. Therefore, we need a public place to publish transactions, and everyone can query the transactions from there.
Order consensus: In computer systems, the physical time we usually experience does not exist. In distributed systems, time is often Lamport timestamps, which do not provide a measure for our physical time but order our transactions.
Validation (Optional): Validation on Bitcoin involves verifying signatures and the amounts transferred in BTC transactions. However, Peter Todd believes that this validation is not necessary for building a token system on top of Bitcoin; it's just an optimization option.

At this point, you might recall OmniLayer, which we discussed earlier. OmniLayer itself doesn't delegate state computation and validation to Bitcoin, but it does reuse Bitcoin's security. Colored Coins, on the other hand, entrusts state tracking to Bitcoin. The existence of these two systems has already demonstrated that validation doesn't necessarily have to occur on the blockchain.

So how does client side validation effectively verify transactions?

First, let's look at what needs to be verified:

State (transaction logic verification)
Verify that the inputs (TxIn) are valid to prevent double-spending.

It's easy to notice that for assets issued on Bitcoin, every transaction requires verification of the entire relevant transaction history to ensure the referenced inputs haven't been spent and the state is correct. This is highly impractical. So, how can we improve this?

Peter Todd suggests that we can simplify this process by changing the focus of the verification. Instead of confirming that output hasn't been double-spent, this method focuses on ensuring that the inputs of a transaction have been published and do not conflict with other inputs. By ordering the inputs in each block and using a Merkle tree, this type of verification can be done more efficiently because it only requires a small portion of data each time, not the entire chain history of the input.

The commitment tree structure proposed by Peter Todd is as follows:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

But how can we store such a commitment tree on the blockchain? This is where we can introduce the concept of a "single use seal."

Single Use Seal

Single Use Seal is one of the core concepts for understanding CSV. It’s similar to the physical, one-time use seal used to protect cargo containers. A single use seal is a unique object that can be closed precisely once on a message. In simple terms, a single use seal is an abstract mechanism used to prevent double-spending.

For the SealProtocol, there are three elements and two actions.

Basic elements:

l: seal
m: message, which is the information or transaction
w: witness, someone or something that can verify the seal

Basic operations: There are two basic actions:

Close(l, m) → w: Close the seal l on message m, producing a witness w.
Verify(l, w, m) → bool: Verify whether seal l has been closed on message m.

The security of a single use seal implementation means that an attacker cannot find two different messages m1 and m2 such that the Verify function returns true for the same seal.

In simple terms, a Single Use Seal ensures that a certain asset or piece of data is only used or locked once. In Bitcoin's context, this usually means a UTXO can only be spent once. So, Bitcoin transaction outputs can be seen as single use seals, and when an output is used as an input in another transaction, that seal is "broken" or "used."

For assets on Bitcoin, Bitcoin itself acts as the "witness" (w) for the single use seal. This is because to verify a Bitcoin transaction, nodes must check that each input of the transaction references a valid and unspent UTXO. If a transaction tries to double-spend a UTXO that has already been used, Bitcoin's consensus rules and the network of honest nodes will reject that transaction.

To put it even simpler:

A single use seal treats any blockchain like a database, where we store a commitment to a certain message and maintain its status as either spent or unspent.

Summarizing the above, assets that use client side validation have the following characteristics:

Off-chain Data Storage: The transaction history, ownership, and other relevant data of assets using client-side validation are mostly stored off-chain. This greatly reduces the need for on-chain data storage and helps enhance privacy.
Commitment Mechanism: Although asset data is stored off-chain, changes or transfers of this data are recorded on-chain through commitments. These commitments allow on-chain transactions to reference off-chain states, ensuring the integrity and immutability of off-chain data.
On-chain Witnesses (Not Necessarily BTC): Even though most of the data and validation occur off-chain, assets using client-side validation can still leverage the security of the underlying blockchain (proof of publication, transaction ordering) through commitments embedded on-chain.
Validation Work Done on the Client Side: Most of the validation work is done on the user's device. This means that not every node in the network needs to participate in validating each transaction; only the parties involved need to verify the validity of the transaction.

For those using assets with client-side validation, there's an additional point to note:

When transacting and validating assets with client side validation off-chain, it's necessary to not only present the private key that holds the asset but also to provide a complete Merkle path proof for the corresponding asset.

RGB, the pioneer of CSV

The concept of RGB was proposed by Giacomo Zucco, a well-known figure in the community, after 2015. This was a period when Ethereum was on the rise, ICOs (Initial Coin Offerings) were proliferating, and many attempts were made to create projects beyond Bitcoin, such as Mastercoin and Colored Coins.

Giacomo Zucco was disappointed with these developments. He believed that none of these projects matched Bitcoin's potential and that previous attempts to implement tokens on Bitcoin were inadequate. During this time, he encountered Peter Todd and became fascinated with Todd's ideas on Client-Side-Validation (CSV). This led him to propose the idea of RGB.

Apart from the previously mentioned characteristics of assets that use client-side validation, the major difference with RGB and earlier asset protocols is the addition of an execution VM (Virtual Machine) for Turing-complete contract execution. To ensure the security of contract data, Schema and Interface were designed. The Schema, similar to Ethereum's, declares the content and functions of a contract, while the Interface is responsible for the implementation of specific functions, akin to interfaces in programming languages.

These contracts' schemas are responsible for restricting behaviors that exceed expectations during VM execution. For example, RGB20 and RGB21 are respectively responsible for imposing certain restrictions on fungible and non-fungible tokens during transactions.

The commitment mechanism used in RGB, Pedersen Hash

Its advantage lies in its ability to commit to a value without disclosing it. Using Pedersen Hash to build a Merkle tree means that you can create a privacy-protecting Merkle tree that can hide its values. This structure is useful in certain privacy-preserving protocols, such as some anonymous cryptocurrency projects. However, it may not be suitable for CSV assets, which will be mentioned later in comparison with Taproot Assets.

Virtual Machine Design for RGB Simplicity → AluVM

RGB aimed not only to implement a client-side validated asset protocol but also to extend to Turing-complete virtual machine execution and contract programming. Initially, RGB claimed to use a programming language called Simplicity, which generates a proof of execution and allows formal verification (to avoid bugs) of contracts written in it. However, the development of this language did not go as planned, leading to complications that ultimately hindered the entire RGB protocol. Eventually, RGB started using a VM called AluVM, developed by Maxim, with the goal of avoiding any undefined behavior, similar to the original Simplicity. The new AluVM is said to be replaced in the future by a programming language called Contractum, moving away from its current use of Rust.

RGB layer2 scaling direction: Lightning network or Sidechain?

Client-side validated assets cannot continuously trade securely off-chain because they still rely on L1 for transaction publication and ordering. This means that without a layer 2 scaling solution, their transaction speed is still limited by the block production speed of their L1 witness. This implies that if RGB transactions are directly conducted on Bitcoin, under strict security requirements, the time between two related transactions would need to be at least ten minutes apart (BTC's block time), which is often unacceptably slow.

RGB and the Lightning Network

In simple terms, the Lightning Network operates by having the parties to a transaction sign a bunch of contracts (commitment transactions) off-chain. These contracts ensure that if any party violates the agreement, the aggrieved party can submit the contract (commitment transaction) to BTC for settlement, retrieve their funds, and penalize the violator. In other words, the Lightning Network ensures the security of off-chain transactions through protocol and game-theoretic design.

RGB could construct its own Lightning Network infrastructure by designing payment channel contract details suitable for RGB itself. However, building such an infrastructure is not easy due to the high complexity of the Lightning Network, especially considering Lightning Labs' years of work in this field and LND's market share of over 90%.

RGB's Sidechain Prime

LNP-BP, the current maintainer of the RGB protocol, released a proposal in June 2023 by Maxim for a client-side validated asset scaling solution called Prime. In it, Maxim criticized existing sidechain and Lightning Network scaling solutions for being too complex in development. He expressed his belief that, apart from Prime, the other expansion methods, including NUCLEUS multi-node Lightning channels and Ark/Enigma channel factories, would require more than two years of development. However, Prime could be completed in just one year.

Prime is not designed as a traditional blockchain. Instead, it's a modular proof-publishing layer created specifically for client-side validation. It consists of four main components:

Timestamping Service: This service can finalize a sequence of transactions in as little as 10 seconds.
Proofs: These are stored in the form of Partial Merkle Trees (PMTs) and are produced and published alongside block headers.
Single Use Seals: This is an abstract single use seal protocol designed to prevent double-spending. When implemented on Bitcoin, it can be bound to UTXOs, similar to the current RGB design.
Smart Contract Protocol: Sharded contracts for RGB (which can be replaced)

From this, we can see that to address the issue of transaction confirmation times in RGB, Prime utilizes a timestamping service to quickly confirm off-chain transactions and package them with IDs into blocks. At the same time, transaction proofs on Prime can be further consolidated through PMTs and then anchored onto BTC in a checkpoint-like manner.

Taproot-based CSV Assets Protocol: Taproot Assets

Taproot Assets is a CSV asset protocol based on Taproot, designed for issuing assets on the Bitcoin blockchain. These assets can be traded instantly, in large volumes, and at low cost via the Lightning Network. The core of Taproot Assets is the utilization of Bitcoin's security and stability along with the speed, scalability, and low cost of the Lightning Network. The protocol was designed and developed by roasbeef, the CTO of Lightning Labs. Roasbeef is likely the only person on the planet who has personally led the development of both a Bitcoin client (BTCD) and a Lightning Network client (LND), demonstrating a profound understanding of BTC.

Taproot transactions only carry the root hash of the asset script, making it difficult for external observers to identify whether they involve Taproot Assets, because the hash itself is generic and can represent any data. With the Taproot upgrade, Bitcoin gained the ability to execute smart contracts (TapScript). Building on this, the asset encoding of Taproot Assets essentially creates a token definition similar to ERC20 or ERC721. Thus, Bitcoin not only acquires the capability to define assets but also gains the ability to write smart contracts, laying the groundwork for a token smart contract infrastructure for Bitcoin.

The encoding structure of Taproot Assets is as follows:

by roasbeef, CTO of Lighting Labs

Also as a CSV asset protocol, Taproot Assets has a more concise design compared to RGB. The biggest difference between Taproot Assets and RGB in terms of application scalability lies in the execution VM, Taproot Assets uses the same TaprootScript VM as BTC's native default. In recent years, many of the research for the BTC In recent years, a lot of infrastructure research for BTC has been based on TapScript, but due to the slow upgrading of BTC, it cannot be applied in a short period of time, so it can be predicted that Taproot Assets will be a testing ground for these fresh ideas in the future.

Differences between Taproot Assets and RGB

1. Transaction Validation and Light Node Friendliness

Taproot Assets, due to the implementation of a sum tree, has high verification efficiency and security. It allows for state verification and transactions to be conducted simply by possessing a proof, without the need to traverse the entire transaction history. In contrast, RGB's use of Pedersen commitments makes it difficult to effectively verify the validity of inputs. As a result, RGB requires tracing back through the transaction history of inputs, which can become a significant burden as transactions accumulate over time. The design of the Merkel sum tree also enables Taproot Assets to easily facilitate light node verification, a feature that was previously unavailable in asset protocols built on top of Bitcoin.

2. Execution VM

Taproot Assets was developed in response to the Taproot upgrade of the Bitcoin network. It utilizes TaprootScriptVM, which is the script execution engine that comes with Bitcoin following the Taproot upgrade. Moreover, it uses vPSBT, a variant of Bitcoin's PSBT, indicating that once the Taproot Assets lightning channel mechanism is developed, it can immediately reuse all the current infrastructure of LND (Lightning Network Daemon), as well as previous products from Lightning Labs (LND currently holds over 90% market share in the lightning network). Additionally, the recent popular BitVM proposal is based on TaprootScript, which theoretically means all these improvements could eventually benefit Taproot Assets.

However, RGB operates somewhat differently. Its virtual machine and validation rules (SCHEMA) are part of a self-contained system, forming a somewhat closed-off ecosystem. RGB operates within its own ecosystem, and its relationship with the broader Bitcoin ecosystem is not as close as some might think. For instance, with respect to the Taproot upgrade, RGB's only real interaction is encoding commitment data onto the blockchain in the Witness TapLeaf. This illustrates that RGB and the Taproot upgrade are only minimally connected.

3. Smart Contracts

In the current implementation of RGB, contracts and the VM are heavily emphasized. However, in Taproot Assets, there doesn't seem to be a focus on smart contracts, at least not yet. The current RGB implementation has not yet explained how modifications to the Global State synchronize with individual contract shards (UTXO). Moreover, while Pedersen commitments can ensure the total amount of assets, it's unclear how other states would be protected from tampering, as there has not been much explanation on this.

On the other hand, Taproot Assets has a simpler design, but currently only stores asset balances and doesn't handle more complex states, making smart contract discussions premature. However, according to Lightning Labs, there are plans to focus on smart contract design for Taproot Assets next year.

4. Synchronization Center

The basic principle mentioned earlier regarding assets that are verified on the client-side indicates that holding the Proof is as important as holding the private key. However, there's a risk of losing the Proof since it's kept on the client side. How can this be addressed? In Taproot Assets, this issue can be avoided through the use of a "universe." A universe is a publicly auditable sparse Merkle tree that covers one or more assets. Unlike a standard Taproot asset tree, a universe is not used to custody Taproot assets. Instead, it commits to a subset of one or more asset histories.

In the RGB system, this role is fulfilled by Storm, which synchronizes off-chain proof data through a peer-to-peer (p2p) network. However, due to historical reasons associated with the RGB development team, these teams currently use incompatible proof formats. The RGB ecosystem team, DIBA, has indicated that it will develop "carbonado" to address this issue, but its progress is unclear.

5. Engineering Implementation

All the libraries used by Taproot Assets are well-tested, as Lightning Labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and a wide array of wallet library implementations. In contrast, most of the libraries used for the RGB implementation are self-defined. From an industry standards perspective, the implementation of RGB is still in the experimental stage.

A brief look at the future of BTC scaling

Continuing the discussion, it becomes apparent that client-validated asset protocols have moved beyond the scope of traditional protocols and are now heading towards computational scaling.

Many people claim that in the future, Bitcoin will exist as 'digital gold,' while other blockchains will create application ecosystems. However, I hold a different opinion. As seen in many discussions on Bitcoin forums, there's a lot of talk about various alt-coins and their fleeting lifespans. The rapid demise of these alt-coins has turned the capital and effort surrounding them into bubbles. We already have Bitcoin as a strong foundation of consensus; there's no need to build new Layer 1 (L1) solutions just for application protocols. What we should do is leverage Bitcoin, this robust infrastructure, to build a more long-term decentralized world.

Less on-chain computation, more on-chain verification

From the perspective of application design, Bitcoin early on chose a philosophy centered not on on-chain computation but on verification (Turing completeness and state for smart contracts). The essence of a blockchain is a replicated state machine. If a blockchain's consensus focuses on on-chain computation, it's hard to argue that having every node in the network repeat these computations is a reasonable or scalable approach. If the focus is on verification, then validating off-chain transactions might be the most suitable approach for Bitcoin's scalability.

Where does verification take place? This is crucial.

For developers creating protocols on top of Bitcoin, how to use Bitcoin for critical verification, or even to place verification off-chain, and how to design secure schemes, are matters for the protocol designers themselves. They shouldn't and don't need to be associated with the chain itself. How to implement verification will lead to different scaling solutions for BTC.

From the perspective of verification-based implementations, we have three directions for scaling:

1. Verification on-chain (OP-ZKP)

Implementing OP-ZKP directly in TaprootScriptVM would endow Bitcoin itself with the capability to perform ZKP verification. This, coupled with some Covenant design settlement protocols, could create a Zk-Rollup scaling solution that inherits Bitcoin's security. However, unlike deploying a verification contract on Ethereum, Bitcoin's upgrades are inherently slow, and adding such a specialized, potentially upgrade-needy op-code is bound to be challenging.

2. Verification on semi-on-chain (BitVM)

The design of BitVM ensures that it is not intended for ordinary transaction logic. Robin Linus has also indicated that the future of BitVM lies in creating a free cross-chain market for various SideChains. BitVM's approach is considered semi-on-chain because most verification computations will not occur on-chain but off-chain. The significant reason for designing around Bitcoin's Taproot is to utilize TapScriptVM for computational verification when necessary, theoretically inheriting Bitcoin's security. This process also generates a verification trust chain, such as only needing one honest verifier among 'n' verifiers, known as Optimistic Rollups.

BitVM incurs significant on-chain overhead, but can it use ZK fraud proofs for efficiency gains? The answer is no, as the implementation of ZK fraud proofs relies on the ability to perform ZKP verification on-chain, leading us back to the difficulties of the OP-ZKP approach.

3. Verification off-chain (Client Side Validation, Lightning Network)

Complete off-chain verification refers to the previously discussed CSV asset protocols and the Lightning Network. As seen in the previous discussions, we can't entirely prevent collusion in CSV designs. What we can do is use cryptography and protocol design to keep the damage from malicious collusion within controllable limits, making such actions unprofitable.

The advantages and disadvantages of off-chain verification are equally clear. The advantage is that it uses minimal on-chain resources and has huge potential for scalability. The disadvantage is that it's almost impossible to fully inherit Bitcoin's security, which greatly limits the types and methods of off-chain transactions that can be conducted. Additionally, off-chain verification also implies that data is kept off-chain, managed by users themselves, which places higher demands on the security of the software execution environment and the stability of the software.

Trend of Scaling Evolution

Currently, popular Layer 2 solutions on Ethereum, in paradigm terms, validate Layer 2 computations through Layer 1, meaning that state computation is pushed down to Layer 2, but verification is still retained at Layer 1. In the future, we could similarly push verification computation off-chain, further unleashing the performance of current blockchain infrastructure.

References

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/
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/
Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf
Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html
Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/
Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/
Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d
Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225
Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20
Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769
BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter
Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin
Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE
Todd, P. (2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement
Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/
Todd, P. (2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals
Todd, P. (2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication
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
Linux Foundation. (2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59
Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/
Linux Foundation. (2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html
Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi
Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/
Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042
Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/
Todd, P. (2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining

nft://undefined/undefined/undefined?showBuying=true&showMeta=true