Original author: Ben (X: @wooooer)
Preface
Asset issuance based on BTC has always been a hot topic. From Colored Coins, which first appeared in 2011, to the recently popular Ordinal protocol, new players and consensus are always emerging in the BTC community, but very few remain. But as the ambitious Lightling Labs announced its plan to build a Stable Coin based on Taproot Assets, Tether also announced that it would choose RGB for the minting of USDT on the Bitcoin layer.
This means that the once-famous OmniLayer (Mastercoin) is no longer the largest player in the BTC ecosystem. Client-side verification (CSV) asset protocols have begun to enter everyone’s field of vision. The difference from traditional BTC asset protocols is that they also bring In order to expand the properties of BTC. But in the face of so many asset protocols in the BTC ecosystem, people cant help but ask, what are their differences? Faced with so many asset protocols, how should we choose and find our own opportunities? This article hopes to lead everyone to review the asset protocols that have appeared in the history of BTC and also explore the future of the development of BTC asset protocols.
Colored Coins: Colored Coins
The idea of Colored Coins was first written by Yoni Assia, now the CEO of eToro, in an article titledbitcoin 2.X (aka Colored bitcoin)Article presented. The article believes that Bitcoin as the underlying technology is perfect, just like HTTP is the foundation of the network. Therefore, the token protocol Colored Coins was designed based on the reuse of BTC.
Yoni Assia hopes to create a BTC 2.0 economy in such a way that any community can create multiple currencies. This method of using Bitcoin as the underlying technology to clear transactions and avoid double payments was undoubtedly a very bold idea at the time.
Colored Coins is a protocol for issuing assets based on Bitcoin. Its approach is to color a certain number of Bitcoins to represent these assets. These tokenized Bitcoins are still functionally Bitcoins, but they also represent another asset or value. But how can such an idea be implemented on Bitcoin?
On July 3, 2014, ChromaWay developed the Enhanced Fill-Order-Based Coloring Protocol (EPOBC), which simplifies the process for developers to create colored coins. This was the first protocol to adopt Bitcoin Scripts OP_RETURN function.
The final effect is shown in the figure below:
This implementation is very simple, but it also brings many problems:
1. Fungible tokens and minimum binding value
If 1000 sat is bound to a dyed coin in the genesis transaction, the minimum splitting unit of the dyed coin is 1 sat. This means that the asset or token can be divided or distributed into up to 1,000 shares (but this is only theoretical, in order to prevent dust attacks, for example, the SAT in the current year is set at 546 SAT, and later it will be higher in ordinal).
2. Verification issues
In order to determine the authenticity of a colored coin and its ownership, verification needs to be traced from the genesis transaction of the asset to the current UTXO. Therefore, it is necessary to specially develop wallets and supporting full nodes, and even browsers.
3. Potential miner censorship risks
Because the characteristics of ColoredTransaction are more obvious, that is, metadata information is written in the output, this brings the possibility of miner review.
Colored coins are actually an asset tracking system that uses Bitcoin’s verification rules to track asset transfers. However, in order to prove that any specific output (txout) represents a specific asset, a complete chain of transfers from the origin of the asset to the present needs to be provided. This means that verifying the legitimacy of a transaction may require a long chain of proofs. In order to solve this problem, someone originally proposedOP_CHECKCOLORVERIFYTo help directly verify the correctness of Colored Coins transactions on Bitcoin, but the proposal did not pass.
Crypto Industry’s First ICO: Mastercoin
The original concept of Mastercoin was proposed by JR Willett. In 2012, he released a"The Second Bitcoin Whitepaper"The white paper described the concept of creating a new asset or token on Bitcoins existing blockchain, which later became known as MasterCoin. Later it was renamed Omni Layer.
The Mastercoin project conducted an initial token sale (today we call it an ICO or initial coin sale) in 2013 and successfully raised millions of dollars in what is considered the first ICO in history. Mastercoins most famous application is Tether (USDT), which is the most well-known legal stablecoin and was originally issued on Omni Layer.
In fact, the idea of Mastercoin appeared earlier than Colored Coins. The reason why I discuss it here as the second one is because compared to Colored Coins, MasterCoin is a relatively heavier solution. MasterCoin builds a complete node layer to provide more complex functions (such as smart contracts), while Colored Coins is simpler and more straightforward, focusing mainly on coloring or marking Bitcoin UTXO to represent other assets.
The biggest difference from Colored Coins is that Mastercoin will only publish various types of transaction behaviors on the chain and will not record relevant asset information. In Mastercoin nodes, a database of state models is maintained in off-chain nodes by scanning Bitcoin blocks.
Compared with Colored Coins, the logic it can complete is more complex. And since the status is not recorded and verified on the chain, there is no requirement for continuity (continuous coloring) between transactions.
However, in order to implement the complex logic of Mastercoin, users need to trust the status in the off-chain database in the node, or allow the Omni Layer node to verify it themselves.
Summarize:
The biggest difference between Mastercoin and Colored Coins is that it does not choose to maintain all the data required for the protocol on the chain. Instead, it parasitizes the BTC consensus system to implement its own transaction publishing and sorting, and then maintains the status in the off-chain database. .
According to information provided by OmniBolt: Omni Layer is proposing a new UBA (UTXO Based Asset) asset protocol to TEDA, which will use Taproot upgrades to incorporate asset information into tapleaf to achieve conditional payment and other functions. At the same time, OmniBolt is introducing Stark into OmniLayers Lightning Network facility.
Client Side Validation idea
If we want to understand the concept of client-side verification, then we have to go back to the second year when Colored Coins and Mastercoin appeared, that is 2013. Peter Todd published articles during the year:Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. Although the name of the article seems to have nothing to do with client-side verification, if you read it carefully, you can find that this is the earliest enlightenment idea about client-side verification.
Peter Todd was an early researcher of Bitcoin and cryptography, always looking for a way to make the way Bitcoin work more efficient. He developed a more sophisticated client-side validation concept based on the concept of timestamps. In addition, he also proposed the concept of single use seal, which will be mentioned later.
Now let us follow Peter Todds thoughts and first understand what kind of problems BTC actually solves. According to Peter Todd, it seems that BTC solves three problems in total:
Proof-of-publication
The essence of the release of the proof is to solve the double-spending problem. For example, Alice wants to transfer some Bitcoins to Bob. Although she signed a transaction and transferred it to Bob, Bob does not necessarily know that such a transfer exists physically. . So we need a public place to publish transactions, and everyone can query transactions from there.
Transaction ordering (Order consensus)
In computer systems, there is no physical time as we usually experience it. In a distributed system, this time is usually a distributed clock lambor. This clock does not provide a measurement for our physical time, but sequences our transactions.
Transaction Validation (optional)
Verification on BTC is about the verification of signatures and BTC transfer amounts. But here, Peter Todd believes that this verification is not necessary for building a token system on top of BTC, and is just an optimization option.
When you see this, you have actually thought of the Ominilayer mentioned before. OminiLayer itself does not hand over the calculation and verification of the state to BTC, but it also reuses the security of BTC. Colored Coins hands over status tracking to BTC. The existence of these two has proven that verification does not have to happen on-chain.
So how does client-side verification effectively verify transactions?
First, let’s take a look at what needs to be verified:
1. Status (transaction logic verification)
2. Check whether the input TxIn is valid (to prevent double spending)
It is easy to find assets published on Bitcoin. Each transaction needs to verify the entire related transaction history to ensure that the referenced input has not been consumed and the status is correct. This is very unreasonable, so how to improve it?
Peter Todd believes we can simplify this process by changing the focus of verification. Rather than confirming that an output has not been double-spended, this approach focuses on confirming that the transactions inputs have been posted and do not conflict with other inputs. By sorting the inputs in each block and using Merkle trees, this verification can be done more efficiently, since each verification only requires a small portion of the data rather than the entire on-chain history of that input.
The commitment tree structure proposed by Peter Todd is as follows:
CTxIn -> CTxOut ->
But how do we store such a commitment tree on the chain? So here we can introduce the concept of single use seal.
Single Use Seal
One of the core concepts in understanding client-side validation is single use seal, which is similar to the physical, single-use seals used to protect shipping containers in the real world. A single use seal is a unique object that can be closed exactly once on a message. In short, a one-shot seal is an abstract mechanism used to prevent double spending.
For SealProtocol, there are three elements and two actions.
Basic elements:
l： seal,that is, seal
m： message,information
w：witness,witness
Basic operations: There are two basic operations:
Close(l,m) → w: Close seal l on message m, producing a witness w.
Verify(l, w,m) → bool: Verify that seal l is closed on message m.
In terms of security, the implementation of single use seal cannot allow an attacker to find two different messages m 1 and m 2, and makes the Verify function return true for the same seal.
First of all, Single-Use Seal is a concept that ensures that a certain asset or data is only used or locked once. In the context of Bitcoin, this usually means that a UTXO (unspent transaction output) can only be spent once. Therefore, the output of a Bitcoin transaction can be considered a one-time seal, and when this output is used as an input to another transaction, the seal is broken or used.
For CSV assets on BTC, Bitcoin itself acts as the witness of a single seal. This is because, in order to validate a Bitcoin transaction, a node must check that each input to the transaction references a valid and unspent UTXO. If a transaction attempts to double-spend a UTXO that has already been spent, Bitcoins consensus rules and honest nodes across the network will reject the transaction.
Can it be simpler?
Single use seal is to treat any blockchain as a database. We store the promise of a certain message in this database in some way, and maintain a consumed or to-be-consumed status for it.
Yes, its that simple.
To sum up, client-verified assets have the following characteristics:
Off-chain data storage:Client-verified assets have mostly their transaction history, ownership and other related data stored off-chain. This greatly reduces on-chain data storage needs and helps improve privacy.
Commitment mechanism:Although asset data is stored off-chain, changes or transfers to this data are recorded on-chain through commitments. These commitments enable on-chain transactions to reference off-chain states, thereby ensuring the integrity and non-tamperability of off-chain data.
On-chain witness (not necessarily BTC):While most of the data and verification is off-chain, client-verified assets can still take advantage of the security of the underlying chain (issuance of proofs, ordering of transactions) through commitments embedded on-chain.
Verify job client completes:Most of the verification work is done on the users device. This means that all network nodes do not need to participate in verifying each transaction, only the participants involved need to verify the validity of the transaction.
For those who use client-side verification of assets, there is another point to note:
When trading off-chain and verifying assets verified by the client, you must not only present the private key holding the asset, but also present proof of the complete merkel path of the corresponding asset.
The Pioneer in Client Side Validation (CSV): RGB
The concept of RGB was proposed by Giacomo Zucco, a well-known figure in the community, after 2015. Due to the rise of Ethereum and the proliferation of ICOs, and before ICOs, many people tried to do something outside of Bitcoin, such as Mastercoin and Colored Coins projects .
Giacomo Zucco expressed his disappointment. He believes that these projects are inferior to Bitcoin, and he believes that the previous ways of implementing tokens on Bitcoin are inappropriate. In the process, he met Peter Todd and became fascinated with Peter Todds idea of Client-Side-Validation. Then he started to proposeRGBidea.
The biggest difference between RGB and previous asset protocols is that in addition to the previously mentioned features of client-side asset verification, it also adds an execution VM to implement a Turing-complete contract execution engine. In addition, in order to ensure the security of contract data, Schema and Interface are also designed. Schema is similar to Ethereum, declaring the content and functions of the contract, while Interface is responsible for the implementation of specific functions, just like the interface in programming languages.
The schemas of these contracts are responsible for limiting behaviors that do not exceed expected behavior when the vm is executed, such as RGB 20 and RGB 21, which are respectively responsible for some restrictions on the transactions of fungible tokens and non-fungible tokens.
RGBs commitment mechanism PerdersenHash
From the perspective of commitment mechanism, RGB uses Perdersen hashing. The advantage is that you can promise a value without disclosing it. Using Pedersen hashes to build Merkle trees means that you can create a privacy-preserving Merkle tree that hides the values within it. This structure can be used in some specific privacy protection protocols, such as some anonymous cryptocurrency projects. But it may not be applicable to CSV assets, which will be mentioned later in the comparison with Taproot Assets.
RGB virtual machine design Simplicity → AluVM
The goal of RGB is not only to implement a client-verified asset protocol, but also to expand to Turing-complete virtual machine execution and contract programming. In the early design of RGB, it claimed to use a programming language called Simplicity. The characteristic of this language is that it will generate an execution proof when executing an expression, and it can make it easier to formalize the contract it writes. Verification (avoiding bugs). However, the development of the language was not ideal and ended up in trouble. This ultimately directly led to the difficulty of the entire RGB protocol that year. Finally, RGB began to use 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 use a programming language called Contractum in the future to replace the currently used Rust.
RGB layer 2 expansion direction: Lightning network or side chain?
There is no way for client-side verification assets to be continuously traded off-chain while ensuring security. Because assets verified by the client still rely on L1 for transaction publishing and sequencing, when there is no L2 expansion plan, its transaction speed will still be limited by the block production speed of its L1 witness. This means that if RGB transactions are conducted directly on Bitcoin, under strict security requirements, the time between two related transactions needs to be up to ten minutes apart (BTC block time). There is no doubt that such transaction speed is unacceptable most of the time.
RGB and Lightning Network
Simply put, the principle of the Lightning Network is that the two parties to the transaction will sign a bunch of contracts (commitment transactions) off-chain to ensure that if either party violates the contract, the offended party can change the contract ( Commitment transaction) is submitted to BTC for settlement, withdrawing ones own funds and punishing the other party. In other words, the Lightning Network ensures the security of off-chain transactions through the design of protocols and games.
RGB can build its own Lightning Network facility by designing its own payment channel contract details that are applicable to RGB. However, the complexity of the Lightning Network is extremely high, and it is not easy to build this facility. However, Lightnling labs has been working in this field for many years, and LND has more than 90% market share.
RGB Sidechain Prime
LNP-BPAs the maintainer of the current RGB protocol, Maxim released a proposal called ** in June 2023Prime**’s client verifies the asset expansion plan, and criticizes the existing side chain and lightning network expansion plans for being too complex in terms of development.MaximSaid that he believes that in addition to Prime, other expansion methods include NUCLEUS multi-node lightning channel and Ark/Enigma channel factory, both of which require more than two years of development. But Prime only takes a year to complete.
Prime is not a blockchain design in the traditional sense, but a modular proof publishing layer designed for client verification, which consists of four parts:
Timestamp service:A transaction sequence can be finalized in as little as 10 seconds.
prove:It is produced and released together with the block header by storing it in PMT form.
Disposable seal:An abstract single-time sealing protocol is sufficient to prevent double spending. If implemented on Bitcoin, it can be bound to UTXO, similar to the current RGB design.
Smart contract agreement:Sharding Contract-RGB (replaceable)
It can actually be seen from this that in order to solve the problem of RGB transaction confirmation time, Prime uses a timestamp service to quickly confirm off-chain transactions and load transactions and IDs into blocks. And at the same time, the transaction proof on prime can be further merged through PMT and then anchored to BTC in a checkpoint-like manner.
CSV asset protocol based on Taproot: Taproot Assets
Taproot Assets is a CSV asset protocol based on Taproot, which is used to issue client-verified assets on the Bitcoin blockchain. These assets can be traded instantly, with high volume and low fees through the Lightning Network. At its core, Taproot Assets leverages the security and stability of the Bitcoin network with the speed, scalability and low fees of the Lightning Network. The protocol was designed and developed by roasbeef, CTO of Lightnling labs. Roasbeef may be the only Bitcoin developer on Odaily who has personally led the development of Bitcoin client (BTCD) and Lightning Network client (LND), and has a deep understanding of BTC.
Taproot transactions only carry the root hash of the asset script, making it difficult for outside observers to identify whether Taproot Assets are involved because the hash itself is universal and can represent arbitrary data. With the Taproot upgrade, Bitcoin gained smart contract (TapScript) capabilities. On this basis, the asset coding of Taproot Assets is equivalent to creating a token definition similar to ERC 20 or ERC 721. In this way, Bitcoin not only has the function of asset definition, but also has the ability to write smart contracts, thus laying the prototype of the token smart contract infrastructure for Bitcoin.
The encoding structure of Taproot Assets is as follows:
Image from Lightning Labs CTO roasbeef
Also as a CSV asset protocol, Taproot Assets has a simpler design than RGB. And it makes the most of the current progress of the BTC ecosystem, such as Taproot upgrade, PSBT, etc. The biggest difference between Taproot Assets and RGB in terms of application scalability is the execution VM. Taproot Assets uses the same TaprootScriptVM as BTCs native default. In recent years, many infrastructure research on BTC have been conducted based on TapScript. However, due to the slow upgrade of BTC, it cannot be applied in a short period of time. It is foreseeable that Taproot Assets will be a test field for these fresh ideas in the future.
What is the difference between Taproot Assets and RGB?
1. Transaction verification and light node friendliness
Taproot Assets has high verification efficiency and security due to the implementation of sum tree (it is possible to verify the status and conduct transactions only through the proof of holding, without the need to traverse and enter all transaction history). The pedersen commitment used by RGB makes it unable to effectively verify the validity of the input, causing RGB to need to trace back the input transaction history. The derivative transaction will be a very heavy burden in the later stage. The design of Merkel sum also allows Taproot Assets to easily implement light node verification, which is not available in previous asset protocols based on BTC.
2. Execute VM
Taproot Assets was born in response to the Taproot upgrade. The TaprootScriptVM it uses is the script execution engine that comes with Bitcoin after the Taproot upgrade, and the vPSBT used is a replica of BTCs PSBT. This means that once the development of the lightning channel mechanism of Taproot Assets is completed, All current LND infrastructure can be reused immediately, as well as previous Lightning labs products (LND currently accounts for more than 90% of the Lightning Network). And the recent hot BitVM proposals are all based on TaprootScript. In theory, all these improvements can eventually help Taproot Assets.
But for RGB, its VM and verification rules (SCHEMA) are self-contained, and to some extent it is a relatively closed small ecosystem. RGB-based construction can only operate within its own ecosystem, and its relationship with the Bitcoin ecosystem is not as close as everyone imagines. Taking the follow-up of Taproot upgrade as an example, the only relationship between RGB and Taproot upgrade is to encode the on-chain commitment data into the TapLeaf of Witness.
3. Smart Contract
In the current implementation design of RGB, the contract and VM are a heavily highlighted part. However, in Taproot Assets, there are no smart contracts yet. However, it has not been explained how the current modification of RGB in the current Global State is synchronized with each independent contract shard (UTXO). Moreover, Pedersen promises that it can only guarantee the total number of assets. There seems to be no more explanation on how to ensure that tampering is identified in other states. As for Taproot Assets, although the design is simple, currently only the asset balance is stored for state storage, and there are no more states. We cannot talk about smart contracts for the time being. However, according to Lightning Labs, Taproot Assets will focus on smart contract design next year.
4. Sync Center
From the basic principles of assets verified on the client side mentioned before, we can understand that holding Proof is as important as holding the private key, but if Proof is always on the user client, it may be easily lost, so what should we do? Woolen cloth? In Taproot Assets, we can avoid such problems through universe. A universe is a publicly auditable (MS-SMT) covering one or more assets. Unlike the normal Taproot asset tree, the universe is not used to host Taproot assets. Instead, a universe commits to a subset of one or more asset histories.
The person responsible for this part of RGB is Storm, which will synchronize and store off-chain proof data through p2p. However, due to historical reasons of RGBs development team, the proof formats of these teams are currently incompatible. RGB ecological team DIBA currently states that it will developcarbonadoto solve this problem, but the progress is not yet clear.
5. Project implementation
All libs used by Taproot Assets are time-tested, because Lightning labs has its own Bitcoin client (BTCD), Lightning Network client (LND), and a large number of wallet lib implementations. On the other hand, most of the libs used for RGB implementation are self-defined. From the perspective of industry standards, RGB implementation is still in the laboratory stage.
A brief discussion on the future of BTC expansion
At this point in the discussion, everyone discovered that the client-verified asset protocol has broken away from the scope of the protocol and has begun to move towards computing expansion.
Many people say that Bitcoin will exist as digital gold in the future, while other chains will create an application ecosystem. But I have a different view on this. Just like on the btc forum, a lot of discussions are about various alt-coins and their short lives. The rapid demise of these altcoins has turned the capital and efforts that once surrounded them into a bubble. We already have a strong consensus foundation like Bitcoin, and there is no need to build a new L1 for the application protocol. What we have to do is how to make good use of Bitcoin, the strongest infrastructure, to build a longer-term decentralized world.
Less on-chain computation, more on-chain verification
From the perspective of application design, Bitcoin has long chosen a design philosophy that is not based on on-chain computing as its core goal, but rather on verification (Turing completeness and state for smart contract). The essence of the blockchain is a replicated state machine. If the consensus of a chain is calculated on the chain, it is difficult to say that it is reasonable and scalable to let all nodes in the network repeat these calculations. If verification is the main focus, then verifying the validity of off-chain transactions may be the most suitable solution for BTC expansion.
Where does the verification happen? its important
For protocol developers based on Bitcoin, how to use Bitcoin for key verification, or even put the verification off-chain, and how to design a security solution are actually the protocol designers’ own affairs, and there is no need to do so. It should not have anything to do with the chain itself. So how to achieve verification will lead to different expansion plans for BTC.
So based on the perspective of verification implementation, we have three expansion directions:
1. Verification occurs on-chain (OP-ZKP)
If OP-ZKP is implemented directly in TaprootScriptVM, it is equivalent to adding the ZKP verification capability to BTC itself, and then with some Covenant design settlement protocols, a Zk-Rollup expansion solution that can inherit the security of BTC can be created. But unlike deploying a verification contract on Ethereum, the upgrade of BTC itself is slow, and adding such op-code that is not universal and may require subsequent upgrades is destined to be difficult.
2. Verification occurs on a half-chain (BitVM)
The design of BitVM is destined not to serve ordinary transaction logic. Robin Linus also stated that the future of BitVM is to serve as a free cross-chain market for various SideChains. The reason why BitVMs solution occurs on a half-chain is because most of the time these verification calculations do not occur on the chain, but occur off-chain. However, the important reason for designing around BTCs Taproot is to be able to use TapScriptVM for calculation verification when necessary, which is also to theoretically inherit the security of BTC. In this process, a verification trust chain is also generated. For example, as long as one of the n verifiers is honest, that is, Optimistic Rollups.
BitVMs on-chain overhead is huge, but can ZK fraud proof be used to improve efficiency? The answer is no, because the implementation of ZK fraud proof is based on the fact that ZKP can be verified on the chain, which returns to the dilemma of the OP-ZKP scheme.
3. Validation occurs off-chain (Client-Side-Validation, Lightning Network)
Verification occurs completely off-chain, that is, the CSV asset protocols and Lightning Network discussed previously. As can be seen in the previous discussion, in the design of CSV, we cannot completely prevent the occurrence of collusion tampering. What we can do is to use cryptography and protocol design to keep the scope of such malicious collusion harm within a controllable range. Making this behavior unprofitable.
The advantages and disadvantages of off-chain verification are also very obvious. The advantage is that it takes up very little resources on the chain and has huge potential for expansion. The disadvantage is that it is almost impossible to fully reuse the security of BTC, which greatly limits the types and methods of off-chain transactions that can be performed. And off-chain verification also means that the data is off-chain and is kept by the users themselves, which places higher requirements on the security of the software execution environment and the stability of the software.
The trend of expansion and evolution
From a paradigm perspective, Layer 2, which is currently popular in Ethereum, uses Layer 1 to verify the calculation validity of Layer 2, that is, the state calculation is pushed down to Layer 2, but the verification is still retained on Layer 1. In the future, we can also push the verification calculations off-chain to further release the performance of the current blockchain infrastructure.
References
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
