# About

Welcome to the Stanford Encyclopedia of Bitcoin!

## Introduction

When most outsiders think of “blockchain” or “cryptocurrency,” they immediately think of Bitcoin. Intuitively, this makes sense: Bitcoin is the oldest, most well-known cryptocurrency with the largest market cap. Yet, the informational resources for Bitcoin are very scattered, outdated, and not representative of all the latest innovation happening in the space.

**By creating the Stanford Encyclopedia of Bitcoin (SEB), our goal is to increase transparency of the innovation happening within the Bitcoin community and provide a free, objective, and educational resource for all to understand the Bitcoin space.**

## Content

We hope to create a unique educational resource that “shines a light” on the latest innovations within the space, for innovators, educators, and curious minds to better understand the Bitcoin behind the ticker symbols.

In doing so, we hope to cover topics such as:

* **Innovations on the Base Protocol** (Taproot, DLCs, Miniscript, BIPs)
* **Metaprotocols** (Ordinals, BRC-20, Colored Coins, .sats)
* **Extensibility solutions and protocols** (Federated sidechains, Lightning, zkRollups)
* **Application Layer Innovations** (DeFi, Gaming, Social)

Within each entry, we hope to give a high-level overview of the principles and technical implementation of each topic and protocol, as well as resources for further reading. **We do not plan to include more generic entries on “blockchains,” “cryptocurrencies,” and “consensus,” as there already exist many online courses and resources devoted to these topics.**

## Core Contributors

#### [Stanford Blockchain Club](https://blockchain.stanford.edu/)

SEB is founded and spearheaded by the Stanford Blockchain Club, Stanford University's official student group for everything blockchain, cryptoeconomics, and cryptocurrency. Created as the Stanford Bitcoin Club in 2014, Stanford Blockchain Club has deep ties to Bitcoin and has one of the strongest alumni and community networks within the industry. As one of the oldest and most prominent student blockchain clubs, SBC is a neutral, credible, non-profit organization focusing on increasing educational awareness of the industry.

#### [Bitcoin Startup Lab](https://btcstartuplab.com/)

Bitcoin Startup Lab is a startup program focused on bleeding edge Bitcoin innovation, and a cofounding contributor to the SEB. BSL collaborates with more Bitcoin technologies than any other innovation platform on Bitcoin. One of its flagship projects is the Bitcoin Olympics Hackathon, which aims to cultivate the cross-pollination of ideas and collaboration to enable new Bitcoin innovations.

<br>


# Core Protocol Overview

Within this section, we will explore some of the most important innovations within the Bitcoin Core protocol, as well as how the Bitcoin Core protocol has developed over time.


# Bitcoin Script

TODO: SBC (Jaeyong)


# SegWit Upgrade

Bitcoin Soft-Fork Introduced in 2017

## Introduction

Segregated Witness (SegWit) is a 2017 soft-fork to the Bitcoin protocol introduced in BIP 141, which proposes a solution to the transaction malleability of ECDSA cryptographic signatures that limited the scalability of the original protocol.

It introduces several changes to Bitcoin transactions, including a Block Size Increase, a new Witness Commitment Scheme, and a new SegWit Address standard.

## Background

The SegWit soft-fork aimed to solve the malleability of [ECDSA (Elliptic Curve Digital Signature Algorithm)](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) cryptographic signatures used in Bitcoin transactions.

Using a person's public/secret key pair $$(sk, pk)$$, they can sign a message $$M$$using a signing function and their secret key: $$\sigma = sign(sk, M)$$, obtaining a signature $$\sigma$$. Anyone can verify the signature is valid given the public key of the signer pk, the signed message M, the signature $$\sigma$$, and a verify function: $$Ver(pk,M,\sigma)$$. A secure signature scheme is designed with the property that without knowing the secret key, it would be impossible (in polynomial time) to come up with  such that $$Ver(pk,M',\sigma ')$$ returns true. This means once a message is signed, it is practically impossible to be tempered with.

It turns out ECDSA has this undesired property of malleability: Given $$(pk,M,\sigma)$$ such that $$Ver(pk,M,\sigma)$$ returns true, it is trivial to come up with $$\sigma '$$ such that $$Ver(pk,M,\sigma ')$$ returns true. Thus, it is possible to come up with valid signatures on messages without knowing the secret key with which the message is signed.

Bitcoin protocol requiring UTXO transactions to be signed by the owner when they want to spend them in a transaction, combined with the fact that transactions are identified by TXID which is the hash of the entire transaction, leads to the problem of transaction malleability. In effect, a single transaction may have multiple different TXIDs, and an adversarial party can broadcast transactions with an altered signature.

This thus introduces an attack vector, which has contributed to several major security incidents on the network, including playing a role in the collapse of Mt Gox, a once-popular Bitcoin-fiat exchange platform \[1].

Importantly, this problem of malleability does not severely affect Bitcoin protocol transactions, as transactions are still valid and still cannot be modified once signed. However, the fact that transactions cannot be uniquely identified by TXIDs (their hash) makes it hard to use transactions that are not confirmed on chain, which makes Layer 2 protocols like payment channels hard to build.

## BIP 141

SegWit is introduced in BIP 141, a soft-fork that includes multiple revisions to the original protocol while still being backward compatible.&#x20;

### Change to TX format

1. An emty scriptSig field.
2. n \<pkhash> scriptPubKey field indicating the transaction is a SegWit transaction with version number n.
3. A witness field.&#x20;

Here’s the format of a SegWit native P2WPKH tx:

```javascript
{
   witness:      <signature> <pubkey>
   scriptSig:    (empty)
   scriptPubKey: 0 <20-byte-key-hash>
                  (0x0014{20-byte-key-hash})
}
```

Note with an empty scriptSig and the scriptPubKey being n \<pkhash>, a SegWit transaction will still be considered a valid transaction with no signatures from the point of view of a node that does not support SegWit, this is how BIP 141 achieved backward compatibility. By putting signatures in the witness field, transaction id will now be non-malleable for SegWit transactions.&#x20;

### Block Size Increase

For nodes that do not support SegWit, witness data is ignored and a SegWit transaction is viewed as a non-SegWit transaction with empty scriptSig. As the result of the witness data not being counted towards the size of a SegWit transaction, a SegWit transaction can be much smaller from the view of an old node than from a SegWit compatible node.&#x20;

Although witness data is ignored by the old nodes, SegWit compatible nodes still see and store it. To prevent people from spamming new nodes by issuing transactions with very large witness data, a new rule about block size is introduced in BIP 141: the block size limit is increased to 4 MB, and the way the “size” (defined as block weight in BIP 141) of a block is calculated is by multiplying the size of nonwitness data by 4 and add it to the size of witness data.&#x20;

As a result, there are approximately 80% more transactions per block on average since the introduction of SegWit.

### Witness Commitment&#x20;

A witness commitment scheme is introduced in BIP141.&#x20;

<figure><img src="https://lh7-us.googleusercontent.com/UdX1BqUwSVTA56GgBjOivcfVhpd1E3dlRVimqqMaUm3IXiSAlbVN_sBjZiWxgGCoMsSvV7tRuRJSBA4jA1Ij-i34W4nZT3HkZ7a5EWKBHgB6wc-GRgDWDnb08B2vDX1vuA0sOFw2HgPFv_bSa07LKlI" alt=""><figcaption><p>Image Source: <a href="https://ocw.mit.edu/courses/mas-s62-cryptocurrency-engineering-and-design-spring-2018/resources/mas-s62s18-lec12/">https://ocw.mit.edu/courses/mas-s62-cryptocurrency-engineering-and-design-spring-2018/resources/mas-s62s18-lec12/</a> </p></figcaption></figure>

In order to incorporate the witness data into the Merkle root of a block, a Merkle tree on the witness data is built, then the Merkle root of witness (wit root) is put into the coinbase transaction, which will then be hashed into the Merkel root of all transactions in a block.&#x20;

### Linear Scaling of SigHash Operations&#x20;

Before Segwit, the signature operation is $$O(n^2)$$, because doubling the size of a transaction usually doubles both the number of signature operations as well the amount of data that has to be hashed for those signatures \[5]. This is fixed in BIP 143, which is introduced together with the SegWit upgrade’s BIP 141, by changing the calculation of the transaction hash for the signature such that each byte of data only has to be hashed once \[3]. This makes the operation $$O(n)$$. As a result, very large transactions can be signed and verified in a reasonably fast fashion.

### SegWit Address

The native SegWit transactions’ output addresses cannot be parsed by non-SegWit compatible software.&#x20;

For backward compatibility, BIP141 proposed BIP16 nested SegWit transaction so that SegWit transactions can still be sent and received via software that do not support SegWit. <br>

**P2WPKH nested in BIP16 P2SH:**

```javascript
   witness:      <signature> <pubkey>
   scriptSig:    <0 <20-byte-key-hash>>
                  (0x160014{20-byte-key-hash})
   scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
                  (0xA914{20-byte-script-hash}87)
```

This decision results in three types of addresses:

1. Legacy address starting from 1…
2. Segwit address starting from bc1…
3. Nested SegWit address starting from 3… \[6]

## Legacy and Impact

### Malleability and Lightning Network&#x20;

Malleability is solved by Segwit, as now the signatures of transactions are no longer a part of the hash that determines the TXID. This means that the TXID is unique for every transaction in the network, which makes L2 payment channel possible, in the sense that unconfirmed transactions now won’t have invalid UTXOs in them. This improvement gives rise to the Lightning Network, an L2 protocol that increases the transaction speed and reduces transaction costs.&#x20;

### Block Size Increase and Ordinals

The introduction of the witness data field in the TX format in BIP 141 allows for storing arbitrary data such as text, image, etc on chain, also on a larger volume because the block size is increased as a result of the BIP141. One implication is that NFT, or digital artifacts, is possible to implement now on Bitcoin. Segwit, together with Taproot update, has led to the rise of Bitcoin Ordinals, which is a metaprotocol that allows people to order, identify, and inscribe digital content on satoshis to create digital artifacts.

### Block Size Debate and Bitcoin Cash Hardfork

BIP141 is designed in a backward-compatible manner, as a soft-fork of the protocol. While being a soft-fork has the advantage of better adaptability, some in the blockchain community think BIP 141, especially the increasing of blocksize, should have been implemented as a hard-fork instead of a soft-fork. As the result of this disagreement, a group of developers initiated a hard-fork called Bitcoin Cash, which increases the block size to 8MB.&#x20;

## References

\[1] Mt Gox: <https://www.coindesk.com/markets/2014/02/07/mt-gox-halts-all-bitcoin-withdrawals-price-drop-follows/>

\[2] BIP 141:<https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki>

\[3] BIP 143: <https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki>

\[4] SegWit History: <https://web.archive.org/web/20210224032019/https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality>

\[5] SigOp: <https://en.bitcoin.it/wiki/OP_CHECKSIG>

\[6] Legacy vs Segwit Address <https://medium.com/@buddhasource/bitcoin-legacy-vs-segwit-wallet-address-what-is-the-difference-cb2e71ab8381>

*Edited By: Liwen Ouyang*<br>


# Taproot Upgrade

Bitcoin Soft-Fork Introduced in 2021

The Taproot Upgrade is a soft-fork introduced in 2021, providing the network with increased security, flexibility, and scalability, and the most significant upgrade to the network since the 2017 SegWit upgrade.

The Taproot Upgrade is the combination of three distinct Bitcoin Improvement Proposals (BIPs): BIP 340, which introduces Schnorr Signatures, BIP 341, which introduces a Taproot framework for using these signatures for transactions, and BIP 342, which updates Script with opcodes that support the Taproot framework \[1].<br>

<figure><img src="https://lh7-us.googleusercontent.com/UfP3ecfMF-fg9vnwMXAZdRaDASQr-rlyn-Vs6vlbKhFklyYE752jiR5CiREOh--2JyXAPhjCQtMe4oGxRUg2ZccCr1YHnwfX62wlFaYWstAXO7tWlt7yRffgmiu4849PSUZBiMUNCygZ-wZdtpQlEYE" alt=""><figcaption></figcaption></figure>

## Implementation

### BIP 340: Schnorr Signatures

Bitcoin has historically relied on [ECDSA signatures](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm), which have malleability issues that pose security risks \[2]. One of the most important parts of the Taproot Upgrade is the introduction of [Schnorr Signatures](https://en.wikipedia.org/wiki/Schnorr_signature) \[3], a new signature scheme that hold several advantages over ECDSA, including:

1. **Provable security** – Schnorr signatures have much stronger security properties than ECDSA, and are “strongly unforgable under chosen message attack” ([SUF-CMA](https://blog.cryptographyengineering.com/euf-cma-and-suf-cma/)). This means that even if an attacker has an arbitrary sample of valid signatures by a single party, they cannot “reverse-engineer” the secret key used to generate these signatures.
2. **Non-malleability** – Because of the SUF-CMA property of Schnorr signatures, they do not suffer from the malleability issues of ECDSA signatures.
3. **Efficient signature aggregation** – it is very easy to compute a single aggregate signature for multiple parties using Schnorr signatures, based on the sum of the parties’ public keys. This makes Schnorr signatures much more efficient than ECDSA for multisig wallets, while also offering greater privacy guarantees, as shown in the Diagram below:

<figure><img src="https://lh7-us.googleusercontent.com/C63q5RCUsRNArDkRUkvJvgLRXCEKL3uZ9f2nj5kX82QsbXTTVE055s0v2jlI6O_lVTx85YnlRIbc02NKtpNi_PKNoMEqBef3b0xGg1CvNGs_LiDWnoX0Uwj3tBFSOZSugkmE6LTlidszZV5ri0RUiOc" alt=""><figcaption><p>Image Source: <a href="https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade">https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade</a> </p></figcaption></figure>

Within BIP 340, the authors design a mechanism to standardize Schnorr signatures and make it compatible with the existing cryptographic schemes in Bitcoin. This includes using the same elliptic curve and hash functions as the standard Bitcoin ECDSA signatures, choosing a variant of the Schnorr signature that supports batch verifications \[3].

### BIP 341: Taproot

BIP 341 is the main proposal in which the “Taproot upgrade” is named after. Its main purpose is to introduce a general framework that allows for the integration of several complementary mechanism proposals, such as Schnorr Signatures (BIP 340), Merklized Alternative Script Trees (MAST, BIP 114), and the Pay-to-Taproot (P2TP) merging of pay-to-pubkey and pay-to-scripthash policies \[4].

#### **MASTs**

Merklized Alternative Script Trees (MASTs) \[5], are data structures that succinctly encapsulate all possible scripts needed to unlock a [UTXO (unspent transaction output)](https://developer.bitcoin.org/devguide/transactions.html). Suppose that there are three separate ways to unlock a given UTXO. Instead of writing out every individual script, a MAST allows the user to use a single Merkle to capture all three of these possible scripts, and the recipient only needs to submit a Merkle proof of the redeem script they are using to guarantee that it is covered in the MAST. This can be seen in the following diagram:

<figure><img src="https://lh7-us.googleusercontent.com/ql3nv3YQLffha38BTZyfgM8CF43X4L1oEasVR5t-GnxU--6Ex0AgFHARpaSzpTrLIrJWwUwzrEGlyFjyPbdOPOEO5LPcrrg7DrDbf0lRkmZ8_RSY8432CqD3-GELQa4yIeYAu7DYBne5qKWNg4J3-dQ" alt=""><figcaption><p>Image Source: <a href="https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade">https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade</a> </p></figcaption></figure>

#### **Pay-to-Taproot (P2TP): Unification of P2PKH and P2SH**

Bitcoin originally has [multiple address types for payment](https://unchained.com/blog/bitcoin-address-types-compared/), with two of the most prominent being pay-to-pubkey-hash (P2PKH), where a user directly sends a payment to another user’s “wallet address,” and pay-to-scripthash (P2SH), where the user sends a payment to a Bitcoin Script that defines the unlock criteria for redeeming the transaction.

Pay to Taproot (P2TP) is a method used to unify these two separate architectures. It builds on Schnorr signatures, as they provide a simple way to aggregate multiple signatures, as well as MASTs, which is able to succinctly define multiple unlock conditions. Therefore, P2TP provides an abstraction layer, where a user no longer needs to specifically define if a transaction is P2PKH or P2SH.

#### Taproot Annex

BIP 341 also introduces an extra “annex” section in the witness. This optional “annex” allows the user to inscribe an extra field with the transaction witness. This section was originally intended to allow for future extensions, such as new Script commands, to be backwards compatible with the current version, and as such allows for extra programmability and flexibility for the BItcoin network.

### BIP 342: Tapscript

The third part of the Taproot Upgrade is BIP 342, which modifies Bitcoin Script commands to make them compatible with BIP 340 and BIP 341. The end goal for this BIP is to allow Schnorr signatures, batch validation, and signature hash improvements to spends using the script system. Notably, the OP\_CHECKSIG and OP\_CHECKSIGVERIFY opcodes are modified to support Schnorr signatures. A new command, OP\_CHECKSIGADD is also introduced to support multiple signature verification using Schnorr signatures \[6].

## Impact and Legacy

The Taproot upgrade has had a significant impact to the overall efficiency of the Bitcoin network. Some notable improvements include \[7]:

1. **Security and Privacy:** The Taproot upgrade enhances Bitcoin security and privacy in multiple ways, including Schnorr signatures SUF-CMA properties, as well as forms of abstraction through MASTs and P2TP that makes it harder to discriminate between different types of payment.
2. **Scalability:** The Taproot upgrade increases the scalability of the Bitcoin blockchain by minimizing the amount of signature verifications and data checking necessary, such as the Schnorr signature aggregations (BIP 340, 342), as well as MASTs. This underlying scalability improvement also benefits higher-level applications, such as the Lightning Network.
3. **Programmability Support:** The new Opcodes and increased executional efficiency paves the way for increased smart contract programmability, providing more space to store arbitrary data in the witness, which may be used to inscribe arbitrary data into the transaction witness, including JSON data, smart contract code, or zero knowledge proofs. Combined with the new annex section in the transaction, this could potentially create a much more dynamic programmability layer.

## References

\[1] See: <https://bitcoinmagazine.com/technical/understanding-taproot-in-a-simple-way>&#x20;

\[2] Discussion of Signature Malleability in BIP 146: <https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki>&#x20;

\[3] BIP 340: <https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki>&#x20;

\[4] BIP 341: <https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki>

\[5] Discussion on MASTs in BIP 114: <https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki> &#x20;

\[6] BIP 342: <https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki>&#x20;

\[7] <https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/>

*Edited By: Jay Yu*


# Meta-Protocols Overview

TODO: BSL


# Ordinals

Inscribing Digital Artifacts on Bitcoin

## Introduction

Ordinals, launched in January 2023, introduced a way to track and number individual satoshis, the smallest units of Bitcoin. Using features from Taproot and Segwit Upgrades, Ordinals allows for the creation and transfer of digital artifacts, which are similar to non-fungible tokens, over Bitcoin network’s Layer 1 \[1].

## Ordinal Theory

Ordinals is the numbering scheme that allows for the unique identification, tracking, and transfer of individual satoshis. There are 3 parts to Ordinal Theory \[2]:

1. Numbering: Satoshis are numbered, starting at 0, according to the order in which they are mined.  For example, the genesis block satoshis which are numbered 0 to 49,999,999.&#x20;
2. Rarity: The rarity of ordinals is determined by their position in significant Bitcoin events. For instance, the first satoshi of the block, difficulty adjustment period, halving epoch, and conjunction cycle can be classified from uncommon to mythic rarity, with special consideration for the very first satoshi from the genesis block.
3. Transfers: Ordinals need to be tracked when transferred to preserve integrity and historical traceability. They are traced according to a first-in-first-out (FIFO) system within transactions, where the order of the satoshis being spent in a transaction follows the sequence in which they were originally mined and previously spent, preserving the ordinal numbering throughout transfers.&#x20;

Shown below is a diagram of the transfer process:

<figure><img src="https://lh7-us.googleusercontent.com/Pn6fMqXMFQkY-fkrKRq0j-NCIyOffe5quFa3SYm9Lu7HtSu_9u2RIwqZ9-vDC6Qf6Yrc7Gl8y4CtO9oAqxSxoqBV2OIvYm_NO-binbthRjIPBNT5BuRg_CarhiDq_ih44oVKUOhlmtDCfYFD" alt=""><figcaption><p>Image source: <a href="https://blog.chain.link/ordinals-bitcoin-nfts/">https://blog.chain.link/ordinals-bitcoin-nfts/</a> </p></figcaption></figure>

## Inscriptions and Digital Artifacts

An inscription is the act of embedding arbitrary content, whether it is images, text, or code, onto a satoshi.&#x20;

Inscriptions create digital artifacts, a unique and indivisible token of digital property that can be traded or collected. Unlike many NFTs, the content for digital artifacts is immutable and always stored on-chain. Digital Artifact Inscriptions come with various features \[3]:

### Storage

The Taproot update to Bitcoin introduced a method for creating on-chain digital artifacts through inscriptions using a two-step process: first, a commit transaction is made with a Taproot output that commits a script with any desired content below 4MB. \[4] Second, this output is spent in a reveal transaction, which makes the content publicly visible on the blockchain. The content, which includes a MIME type and the actual data, is serialized within the script using a structure called “envelopes”. This system allows for images, files, and video to be stored as inscriptions.

### Tracking and Transfer of Digital Artifacts

The first satoshi in the input of the reveal transaction is where the inscription is made, ensuring it can be uniquely tracked and managed according to the rules of ordinal theory. When transferring an inscribed satoshi, the sender must construct a transaction that designates a specific UTXO containing the inscribed satoshi as input. The sender then creates an output where the exact amount of satoshis, including the inscribed one, is specified to be sent to the recipient’s UTXO set. \[3]&#x20;

### Child Inscriptions and Recursion

Child Inscriptions and Recursion refer to the ways in which inscriptions can interact with each other to establish lineage or ownership history on the blockchain. Recursion enables inscriptions to reference the content of other inscriptions, providing use cases such as creative reuse and remixing of content. This includes the use of shared code snippets or combining elements from other inscriptions for generative art. Child inscriptions employ recursion to establish provenance; by referencing parent inscriptions, the owner of the parent can establish linkages to its children. A common use case for provenance is in collections, where the children of a parent inscription are members of the same collection. Below is a typical architecture for collections:

Child Inscriptions and Recursion refer to the ways in which inscriptions can interact with each other to establish lineage or ownership history on the blockchain. \[5] Recursion enables inscriptions to reference the content of other inscriptions, providing use cases such as creative reuse and remixing of content. This includes using shared code snippets or combining elements from other inscriptions for generative art. Child inscriptions employ recursion to establish provenance; by referencing the parent inscriptions, the owner of the parent can establish linkages to its children. A common use case for provenance are collections, with the children of a parent inscription being members of the same collection. Shown below is a typical child-parent architecture for collections:  \[6]

<figure><img src="https://lh7-us.googleusercontent.com/QuZHIjmbLVjc24CU_ddR4awt2x-D4d5RZwAPPnBzOK2thAHaO5HwaWVOaAOB3gp7SFS61Yz9wQrg0CriWlO-AWgABqCQtuXeyfSH8gRJu158olo6t63oeOfHKqoNR6QTTigFt-7o5TtIzj1z" alt=""><figcaption><p>Child-Parent Inscriptions</p></figcaption></figure>

## Impact

Ordinals have had a wide-reaching impact on the Bitcoin ecosystem, with tens of millions of inscriptions having been created. \[7] Ordinals have unleashed a wave of creativity, giving way to new capabilities and innovation:

### Notable Collections

Ordinals have led to the creation of many collections. Notable Bitcoin Ordinals collections include:

1. **Twelvefold**: A generative art collection on Ordinals launched by Yuga Labs, the company behind Bored Ape Yacht Club. The auction ended with $16.5 million in sales for the 300-piece collection. \[8]
2. **On-Chain Monkey**:  On Chain Monkey announced the migration of their 10k Genesis collection from Ethereum to Bitcoin, spending over $1 million to inscribe all of its existing artwork on Bitcoin in a single transaction. \[9] Their 3D generative profile picture collection, OCM Dimensions, are inscribed on rare 2009 satoshis and pioneered the use of recursion, provenance, and compression. \[10]
3. **Taproot Wizards**: Taproot Wizards is a profile picture collection of 2,121 wizards referencing the iconic Bitcoin mascot helmed by Bitcoin advocates Udi Wertheimer and Eric Wall. On February 1st, 2023, the team orchestrated the largest block and transaction in Bitcoin history. Over 99% of blockspace (3.96MB) was taken by the inscription of Taproot Wizard Number #0001, shown below: \[11]

<figure><img src="https://lh7-us.googleusercontent.com/SISGlq3O4XbLlJad6MDgKT0qBFJVvBgcMfeajiKSUAP5n-a7dm8URelwBbGvGVAXBBwy0p4yKVWCEZVAc4MsnGtNYe_WV8ajRBWfGK7_-2V9ihfqHq3VWXH217bltMqhjTwotRgpqc9oHvd9" alt=""><figcaption><p>Image source: <a href="https://ordiscan.com/inscription/652">https://ordiscan.com/inscription/652</a> </p></figcaption></figure>

### Ordinals Wallets and Marketplaces

Wallets such as Xverse, Ordinals wallet, and Hiro allow users to receive, store, and inscribe ordinals easily without the need to run a full node. Marketplaces such as Magiceden, Ordswap, and Gamma facilitate the trading of Ordinals. These marketplaces and wallets significantly enhance the accessibility of usability of Ordinals, making it feasible for a wider audience to engage with this new technology.&#x20;

### BRC-20 Standard

Ordinals have also brought about the rise of fungible tokens without the need for another layer through the BRC-20 Standard. BRC-20 tokens are inscribed with JSON (Javascript Object Notation) data, which gives functionality to deploy, mint, and transfer tokens on the Bitcoin network. Tokens such as PEPE, ORDI, and MEME have reached hundreds of millions in market cap, thousands of owners, and brought about BRC-20 Marketplaces. \[12]

### Controversy

The advent of Ordinals has caused much controversy in the Bitcoin community. On one hand, ordinals mean new users and higher fees per block, which provide additional income for miners. Proponents argue that ordinals stave off the impacts that come with halving events, when block mining rewards halve. On the other hand, higher transaction fees have led to concerns about accessibility. Since the cost for decentralized peer-to-peer transactions increases, users who send money over the Bitcoin network might deviate as transaction fees get costly. \[13] Tools have been created that protest the adoption of Ordinals, such as Ordisrespector, a spam patch-filter for nodes that detect Ordinal transactions and reject them. \[14]

## References

\[1] See: <https://blog.chain.link/ordinals-bitcoin-nfts/>

\[2] Ordinal Theory: <https://docs.ordinals.com/overview.html>&#x20;

\[3] Discussion of Inscriptions: <https://docs.ordinals.com/inscriptions.html>&#x20;

\[4] Storage Size: <https://research.aimultiple.com/ordinal-inscriptions/>&#x20;

\[5] Child Inscriptions: <https://docs.ordinals.com/inscriptions/provenance.html>

\[6] Recursion: <https://docs.ordinals.com/inscriptions/recursion.html>&#x20;

\[7] Dashboard of Ordinals Activity: <https://dune.com/dgtl_assets/bitcoin-ordinals-analysis>&#x20;

\[8] See: <https://decrypt.co/122836/yuga-twelvefold-bitcoin-nft-auction-raises-16-million>&#x20;

\[9] See: <https://bitcoinmagazine.com/culture/onchainmonkey-1-million-migrate-nfts-to-bitcoin>&#x20;

\[10] OCM innovative features: <https://onchainmonkey.medium.com/ocm-dimensions-unveiling-the-many-dimensions-of-bitcoin-ordinals-c850688db68e>&#x20;

\[11] See: <https://nftnow.com/guides/taproot-wizards-a-guide-to-the-fastest-growing-bitcoin-ordinals-project/>&#x20;

\[12] BRC-20 Overview: <https://cointelegraph.com/learn/what-is-a-brc-20-token-standard-an-overview>&#x20;

\[13] Pros/Cons of Bitcoin Ordinals: <https://cointelegraph.com/news/ordinals-good-or-bad-for-bitcoin-supporters-and-opposers-raise-voice>&#x20;

\[14] Ordisrespector Controversy: <https://thebitcoinmanual.com/articles/what-is-ordisrespector/> &#x20;

*Edited By: Kole Lee*

<br>


# BRC-20

Technical Standard for Fungible Ordinals on the Bitcoin Blockchain

## Introduction

BRC-20 is an experimental, technical standard to create and trade fungible ordinals on the Bitcoin blockchain.&#x20;

## Technical Implementation

A BRC-20 standard guides the creation of new fungible ordinals. An ordinal is a satoshi, the smallest unit of Bitcoin equivalent to 0.00000001 BTC, which is inscribed with JSON-formatted data \[1]. This information isn’t coded like smart contracts for ERC-20’s—it is directly embedded onto the token and uses a small amount of storage. Inscription was made more efficient and private through [Bitcoin’s Taproot update](https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/). The data inscribed is predominantly text-based, but can also encompass various formats such as audio, video, or image.

<br>

<figure><img src="https://lh7-us.googleusercontent.com/s98s9jGIAH8pUKmFkEW_QKfAgI_9kAEVDQo_wwYJc-z1naukqtRrjiVcy7drh8Weot7FWEokQeduNOGVEaH7uJegUwlpok19lLz-FBabRSuD963lXR9c74371B5jNLMC4NOYHmkIGVa-6bJWczFEXPE" alt=""><figcaption><p>Image Source: https://dune.com/queries/3022084/5020348</p></figcaption></figure>

Ordinals were initially created as collections of unique digital artifacts akin to nonfungible tokens (NFTs), such as Taproot Wizards. However, the BRC-20 standard enables the creation of fungible ordinals. This means they are uniform and interchangeable, much like how one paper dollar can be exchanged for another. These BRC-20 tokens, designed to be compatible with the Ordinals protocol, operate seamlessly on the Layer 1 of the Bitcoin network.

### Ordi

The first BRC-20 token was created in March 2023 by [Domo](https://twitter.com/domodata), documenting the deployment (launch onto the Bitcoin network) of ‘Ordi’.&#x20;

```javascript
{
    "p": "brc-20",
    "op": "deploy",
    "tick": "ordi",
    "max": "21000000",
    "lim": "1000"
}
```

The Ordi token has 5 functions:

1. `p` = Protocol: tells processing systems this is a BRC-20 event
2. `op` = Operation: specific event type (out of deploy, mint, and transfer functions)
3. `tick` = Ticker: of Ordi
4. `max` = Maximum supply: of Ordi
5. `lim` = Mint Limit: Maximum Ordi tokens each user can mint

Only “p”, “op”, “tick”, and “max” are required functions to create a token that is BRC-20 compliant, while the “lim” and “dec” (function to specify the decimal precision) functions are optional \[2]. The Ordi whitepaper has since been regarded as the definitive BRC-20 white paper to create BRC-20 tokens.&#x20;

There are two other operations for BRC-20 tokens: mint and transfer:&#x20;

```javascript
// Function Mint – Source: BRC-20 Gitbook
{
    "p": "brc-20",
    "op": "mint",
    "tick": "ordi",
    "amt": "1"
}
```

```
// Function Transfer – Source: BRC-20 Gitbook
{
    "p": "brc-20",
    "op": "transfer",
    "tick": "ordi",
    "amt": "500"
}

```

The mint and transfer event have the same required specifications with an additional “amt” function, which specifies the amount of tokens minted by the inscriber or the amount of tokens transferred from sender to receiver. Sending BRC-20 tokens from one party to another requires using an ordinal-enabled wallet that has a taproot address. &#x20;

## Current Landscape

The current landscape of BRC-20 tokens has evolved from the original Ordi to primarily utility tokens and memecoins.&#x20;

### Utility Tokens

There are projects innovating in the BRC-20 and Ordinals space that have launched native BRC-20 tokens to fund their development and provide incentives within their ecosystems.&#x20;

For example, $DSWP is the governance token of the Dot Swap protocol, which is a platform that swaps BRC-20 tokens using an automated market maker and liquidity pools. \[3] The $DSWP is a BRC-20 governance token modeled after $UNI from Uniswap, designed to be used as incentives for liquidity providers, support for the growth of the DotSwap ecosystem, and as DAO governance. Liquidity for the token is supported via a liquidity pool from community-funded BTC. Unlike ERC-20 tokens, BRC-20 tokens themselves cannot be programmed to self-execute or enforce any guarantees. Governance for $DSWP is supported by [veTokenomics](https://cointelegraph.com/news/what-is-vetokenomics-and-how-does-it-work), where users lock their $DSWP for a period of time to receive veDSWP token, a representation of their voting power on matters like determining LP rewards, staking rewards, protocol upgrades, partnerships, etc. \[4]&#x20;

Due to the inherent limitations of the Bitcoin blockchain in terms of smart contract functionality, BRC-20 utility tokens face challenges in efficiently handling complex functions commonly seen with ERC-20 utility tokens like distribution mechanisms (ICOs, airdrops), access control, and interactions with other protocols.

### Memecoins

Most BRC-20 tokens that exist today can be classified purely as meme coins. These tokens are primarily created for cultural significance, and drive market activities by speculative trading. BRC-20 tokens are no exceptions to high volatility—the BRC-native meme coin SATS, which draws inspiration from the Satoshi unit of Bitcoin, saw a 470% increase in its value within the first two weeks of December 2023 \[5].

Traditional memecoins have also found their way into the Bitcoin blockchain, such as PEPEBRC (PEPE) or DOG3 (DOGE). BRC-20’s have grown in popularity due to the reputation of the Bitcoin blockchain and opportunities for coin trading and speculative investments. As of today, there have been over 350 BRC-20 tokens created, with a $1.7 trillion market capitalization and $61 billion in trading volume \[6].

## Impact

The influx of minting and reselling of BRC-20 tokens has driven up activity on the Bitcoin network to all-time highs of over 600,000 transactions, double previous levels \[7]. However the Bitcoin network wasn’t designed to support high scale token trading, with a transaction capacity of just 7 transactions per second (compared to Ethereum's TPS of 30 and Solana's TPS of 6500). This limitation leads to real bitcoin transactions being priced out due to rising competitive gas fees, leading to hundreds of thousands of pending transactions in the memepool \[8]. Binance had to close BTC withdrawals for several hours on May 7 because of an overflow of transactions due to the PEPE token \[9].

These negative externalities have urged Bitcoin core developers to find solutions to mitigate the impact of the use of BRC-20 tokens. Luke Dashjr has proposed to extend spam filters to Taproot transactions, while Ali Sherief proposed to “enforce this "censorship" at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions \[10] \[11].

The negative externalities come from the fact that BRC-20 tokens workaround a chain that doesn’t natively support tokens. Despite this, inscription tokens are being adopted to chains that do support programmed tokens, such as Ethscriptions on Ethereum or Doginals or Dogecoin. \[12]. Popular inscription chains include Polygon PoS and Avalanche with over 168 million and 119 million respectively \[13]. Speculation on these coins have seen the adoption of inscription tokens across 13 chains, demonstrating a rapid and widespread interest in the potential of this new vertical. &#x20;

## References

\[1] <https://chain.link/education-hub/brc-20-token#:~:text=BRC%2D20%20is%20an%20experimental,using%20ordinal%20inscriptions%20on%20Bitcoin>.

\[2]<https://domo-2.gitbook.io/brc-20-experiment/>&#x20;

\[3] <https://dotswap.gitbook.io/dotswap/dswp-tokenomics/allocation>

\[4] <https://dotswap.gitbook.io/dotswap/dao-and-governance/voting-power>

\[5] <https://www.okx.com/learn/what-is-sats-bitcoin-brc20-token>

\[6] <https://www.brc-20.io/>&#x20;

\[7] <https://bitinfocharts.com/comparison/transactions-btc-sma7.html#3y>

\[8] <https://unchainedcrypto.com/bitcoin-core-developers-mull-getting-rid-of-brc-20-transactions/>

\[9] <https://cointelegraph.com/news/binance-closes-btc-withdrawals-amid-congestion-on-the-bitcoin-network>&#x20;

\[10] <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021620.html>

\[11] <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021631.html>&#x20;

\[12] <https://www.theblock.co/post/266272/brc-20-style-tokens-are-spreading-to-chains-beyond-bitcoin-but-why>&#x20;

\[13] <https://dune.com/hildobby/inscriptions>

*Edited By: Sarah Zhang*


# Sats Name Service

TODO: BSL


# Extensibility Layer Overview

TODO: BSL


# Lightning Network

TODO: SBC


# Smart Contract Protocols

TODO: SBC (Caroline)


# Bitcoin Rollups

TODO: BSL