A Tour of BTC Ecosystem Scaling Solutions: Where Are Inscriptions Headed?
TechFlow Selected TechFlow Selected
A Tour of BTC Ecosystem Scaling Solutions: Where Are Inscriptions Headed?
Exploring the technical principles and potential security issues of popular inscription ecosystems.
Navigating Web3 tides with focused insightsAuthor: Simon shieh
Introduction
On December 6, 2023, while Bitcoin investors were celebrating the price surge brought by inscriptions on Bitcoin, Luke Dashjr, a developer of the Bitcoin Core node client, poured cold water on the excitement. He argued that inscriptions constitute a "spam" attack and submitted a fix along with a CVE vulnerability report (CVE-2023-50428). This triggered an uproar in the Bitcoin community, which once again plunged into fierce debate—just as it did during the chaos of the 2017 hard fork.
Should Bitcoin prioritize security and abandon some unintended features, or should it embrace unexpected innovations even if they come with slight security risks?
We know that Bitcoin's journey is not just about speculation and hype—it's also an ongoing evolution of its ecosystem and security landscape. This article aims to explore the dual narratives of Bitcoin’s growth: the expanding utility within its ecosystem and the strengthening of its security measures. We will examine how innovation and robust security protocols work together to pave the way for a new era of digital assets.
1 Overview of the BTC Ecosystem and Fundamentals
As the cornerstone of the cryptocurrency revolution, Bitcoin has long been regarded as digital gold—a store of value. While other public chains have seen vigorous innovation in DeFi, Bitcoin has often faded from attention.
Yet, it was precisely on Bitcoin that pioneers first experimented with stablecoins, Layer 2 solutions, and even DeFi. For example, USDT—the de facto fiat currency of the crypto world—was originally issued on Bitcoin’s OmniLayer network. The image below provides a basic technical classification of the Bitcoin ecosystem.
This includes technologies such as bidirectional pegged sidechains, text parsing based on output scripts (OP_RETURN), inscription via Taproot scripts, drivechains enabled by BIP300 upgrades, and the Lightning Network based on state channels.
Some of these terms may be unfamiliar. Don’t worry—we’ll first cover foundational knowledge before diving into the technical principles of each ecosystem component and their associated security concerns.
UTXO Is the Fundamental Unit of Bitcoin Transactions
Unlike Ethereum’s account-based balance system, Bitcoin does not have the concept of accounts. Ethereum uses four complex Merkle Patricia Tries to store and verify changes in account states. In contrast, Bitcoin elegantly solves these problems using UTXOs in a more streamlined manner.
The Four Trees in Ethereum
Bitcoin Inputs and Outputs
UTXO stands for Unspent Transaction Output. Though the term sounds awkward, it becomes clear once you understand the concepts of inputs, outputs, and transactions.
Transaction Inputs and Outputs
Those familiar with Ethereum know that transactions are the basic communication units in blockchain networks. Once a transaction is included in a block and confirmed, it finalizes a change in the chain's state. In Bitcoin, however, transactions are not simple address-to-address state operations—they consist of multiple input and output scripts.
The above image shows a typical 2-input to 2-output Bitcoin transaction. Theoretically, the total amount of BTC in inputs should equal that in outputs. In practice, the difference between inputs and outputs serves as the miner fee, collected by the block-producing miner—equivalent to gas fees in Ethereum.
We can see that when two input addresses transfer BTC, they must provide verification in the input script to prove ownership of those inputs (i.e., previous unspent outputs, or UTXOs). The output script defines the conditions under which the output BTC can be spent—specifically, what conditions must be met when this unspent output is used as an input in a future transaction (for ordinary transfers, this usually means a signature from the output address; e.g., P2wPKH requires a Taproot address signature, while P2PKH requires a legacy address private key signature).
Specifically, the data structure of a Bitcoin transaction looks like this:
A Bitcoin transaction consists of two key components: inputs and outputs. Inputs identify the sender, while outputs specify the recipient and any change (if applicable). Transaction fees are the difference between total inputs and total outputs. Since every transaction input traces back to a prior transaction output, these outputs form the core of the transaction structure.
This creates a chain-like linkage. In the Bitcoin network, every valid transaction can be traced back to one or more previous transaction outputs. These chains begin with mining rewards and end with currently unspent outputs. All unspent outputs across the network collectively constitute the Bitcoin UTXO set (Unspent Transaction Output).
In the Bitcoin network, each new transaction’s inputs must reference unspent outputs. Additionally, each input must be signed with the corresponding private key from the prior output. Every node in the Bitcoin network maintains a record of all current UTXOs to validate the legitimacy of new transactions. Through the UTXO model and signature verification, nodes can validate transactions without needing to reprocess the entire transaction history, simplifying network operation and maintenance.
Bitcoin’s unique transaction structure aligns with the design outlined in its whitepaper, “Bitcoin: A Peer-to-Peer Electronic Cash System.” As an electronic cash system, Bitcoin mimics physical cash transactions. The spendable amount at an address depends on previously received funds. Each transaction spends all available funds at that address, typically sending to two outputs: one for the recipient and one for change—just like receiving change after paying with cash at a store.
Scripts
Scripts play a crucial role in the Bitcoin network. In fact, each output in a Bitcoin transaction points not to a specific address, but to a script. These scripts act as rules defining how recipients can unlock and use the assets locked in the output.
Transaction validity relies on two types of scripts: locking scripts and unlocking scripts. Locking scripts are embedded in transaction outputs and define the conditions required to unlock them. Unlocking scripts correspondingly fulfill these conditions to release UTXO assets and reside in the input section of transactions. The flexibility of this scripting language enables various combinations of conditions, showcasing Bitcoin’s nature as a “partially programmable currency.”
Each node in the Bitcoin network runs a stack-based interpreter that executes these scripts following a “first-in, first-out” logic.
The most classic Bitcoin script types are P2PKH (Pay-to-Public-Key-Hash) and P2SH (Pay-to-Script-Hash). P2PKH is a simple transaction type where the recipient only needs to sign with the corresponding private key to claim the funds. P2SH is more complex—for example, requiring multi-signature combinations before funds can be accessed.
These scripts and validation mechanisms form the core operational framework of the Bitcoin network, ensuring both security and flexibility.
For instance, in Bitcoin, the output script rule for P2PKH is:
Pubkey script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
The input must provide a signature:
Signature script: sig
And for P2SH, the output script rule is:
Pubkey script: OP_HASH160 OP_EQUAL
The input must provide a list of signatures:
Signature script: [sig] [sig...]
In both cases, the pubkey script represents the locking script, and the signature script represents the unlocking script. Commands starting with OP_ are script instructions parsed by nodes. These commands vary depending on the pubkey script and determine the rules for the unlocking script.
Bitcoin’s scripting mechanism is relatively simple—a stack-based engine interpreting OP_ commands, capable of handling only limited script logic. However, it laid the foundation for blockchain programmability. Many subsequent ecosystem projects evolved from this scripting principle. With upgrades like SegWit and Taproot, the variety of OP_ commands has expanded, and script size limits have increased, fueling explosive growth in the Bitcoin ecosystem.
2 Inscription Technology Principles and Security Issues
The popularity of inscription technology owes much to Bitcoin’s SegWit and Taproot upgrades.
Technically speaking, the higher the degree of decentralization in a blockchain, the lower its efficiency tends to be. Take Bitcoin, for example—each block remains capped at 1MB, unchanged since Satoshi Nakamoto mined the genesis block. Faced with scalability challenges, the Bitcoin community did not opt for simply increasing block size. Instead, they adopted “Segregated Witness” (SegWit)—a non-hard-fork upgrade designed to improve network throughput and efficiency by optimizing block data structures.
Segregated Witness (SegWit)
In Bitcoin transactions, data is divided into two main parts: base transaction data and witness data. Base data includes critical financial information like account balances, while witness data verifies user identity. From a user perspective, they primarily care about asset-related details such as balance, not the intricacies of identity verification. In short, recipients mainly care whether assets are spendable, not the sender’s full details.
However, in Bitcoin’s transaction structure, witness data (i.e., signature information) consumes significant storage space, reducing transfer efficiency and increasing transaction costs. To address this, SegWit was introduced—to separate witness data from main transaction data and store it separately. This optimizes storage usage, improves transaction efficiency, and reduces costs.
Thus, without changing the original 1MB block limit, each block can now include more transactions. Witness data (various signature scripts) can occupy up to an additional 3MB, laying the groundwork for richer Taproot script capabilities.
Taproot
Taproot is a major soft-fork upgrade to the Bitcoin network aimed at enhancing privacy, efficiency, and smart contract capabilities. It is considered the most significant advancement since the 2017 SegWit upgrade.
The Taproot upgrade comprises three Bitcoin Improvement Proposals (BIPs): Taproot (Merkelized Abstract Syntax Trees, MAST), Tapscript, and a new Schnorr signature scheme optimized for multi-signature setups. Taproot offers users multiple benefits, including improved transaction privacy, lower fees, and enhanced ability to execute complex transactions—expanding Bitcoin’s application scope.
The Taproot upgrade directly impacts three ecosystems: Ordinals protocol, which leverages Taproot’s script-path spending scripts to attach extra data; the Lightning Network upgrading to Taproot Assets, evolving from simple peer-to-peer BTC payments to supporting issuance of new assets; and BitVM, a newly proposed virtual machine that uses op_booland and op_not in Taproot to embed boolean circuits into scripts, enabling smart contract functionality.
Ordinals
Ordinals is a protocol invented by Casey Rodarmor in December 2022. It assigns a unique serial number to each satoshi (sat) and tracks them through transactions. Anyone can use Ordinals to attach additional data—including text, images, videos—into the Taproot script of a UTXO.
Those familiar with Ordinals know that Bitcoin has a total supply of 21 million BTC, with each BTC consisting of 10^8 satoshis—meaning there are 21 million × 10^8 sats in total. The Ordinals protocol differentiates each sat with a unique identifier. This is theoretically possible, but practically unachievable.
Due to dust attack protection, Bitcoin transactions require a minimum transfer of 546 sats (294 sats for SegWit). Transfers cannot occur at 1-sat granularity. According to Ordinals’ FIFO numbering logic, at least the first 294 sats per block are indivisible.
Therefore, inscriptions are not etched onto individual sats, but rather embedded within a transaction’s script—which must involve at least 294 sats. Centralized indexers (like UniSat) then track and identify the movement of these 294 or 546 sats.
Encoding Method of Inscriptions in Transactions
In principle, Taproot script spending must originate from existing Taproot outputs. Thus, inscriptions should theoretically follow a two-phase commit/reveal process. First, in the commit transaction, create a Taproot input based on script-path spending and specify reveal conditions in the output. Second, in the reveal transaction, spend the output created in the commit phase to publish the inscription content on-chain.
However, in real-world indexer implementations, the reveal transaction is often ignored. Indexers instead directly read script fragments composed of OP_FALSE OP_IF ... OP_ENDIF from the input script to extract inscription content.
Because the OP_FALSE OP_IF instruction combination ensures the script segment won't execute, arbitrary byte content can be stored within it without affecting the original script logic.
A text inscription containing the string “Hello, world!” is serialized as follows:
OP_FALSE OP_IF OP_PUSH "ord" OP_1 OP_PUSH
"text/plain;charset=utf-8" OP_0 OP_PUSH "Hello, world!" OP_ENDIF
The Ordinals protocol essentially serializes this code segment into a Taproot script.
Let’s analyze an on-chain transaction to illustrate the encoding principle of ordinals:
https://explorer.btc.com/btc/transaction/885d037ed114012864c031ed5ed8bbf5f95b95e1ef6469a808e9c08c4808e3ae
We can examine the detailed transaction information:
Analyzing the witness field starting from 0063 (OP_FALSE OP_IF), we can decode the serialized content:
By decoding this portion of the witness script, we can retrieve the inscription content. This example encodes plain text, but similar methods apply to HTML, images, videos, etc.
In theory, you could define your own encoding—even encrypted content known only to yourself—though such content wouldn’t display on standard ordinals browsers.
BRC20
On March 9, 2023, an anonymous Twitter user named domo posted about creating a fungible token standard atop the Ordinals Protocol—called BRC20. The idea was to刻 JSON strings into Taproot scripts via the Ordinals protocol to deploy, mint, and transfer fungible BRC-20 tokens.
Figure 1: Humble Beginnings of BRC-20 Tokens (domo’s first post on the topic)
Source: Twitter (@domodata)
Figure 2: Three Possible Initial Operations for BRC-20 Tokens (p = protocol name, op = operation, tick = ticker/identifier, max = maximum supply, lim = mint limit, amt = amount)
Source: https://domo-2.gitbook.io/brc-20-experiment/, Binance Research
Token creators deploy BRC20 tokens on-chain via the "deploy" function. Participants can then mint tokens at near-zero cost (only paying miner fees). Once the minted amount exceeds "max," further mints are deemed invalid by indexers. After minting concludes, holders can transfer tokens using "transfer" inscriptions.
Notably, Casey Rodarmor, the creator of Ordinals, is highly critical of BRC-20’s dominance in the Ordinals ecosystem. He publicly stated that BRC-20 brought nothing but spam to his creation. Consequently, Casey’s team formally requested Binance remove references linking the ORDI token to the Ordinals protocol, wanting no association between the two.
Extended Protocols
BRC20 Swap
UniSat, currently the largest marketplace, indexer, and wallet provider for inscriptions, has introduced the BRC20 Swap protocol, now available for early adopters.
Previously, inscription trading relied solely on PSBT (Partially Signed Bitcoin Transactions), similar to OpenSea’s off-chain signing model, relying on centralized services to “match” buyer and seller signatures. This restricted BRC20 assets to NFT-style listing models, resulting in low liquidity and poor trading efficiency.
BRC20 Swap introduces a module mechanism within the BRC20 JSON payload, allowing deployment of script-like smart contracts. For example, with the swap module, users can lock BRC20 tokens into the module via a self-transfer transaction. The inscription remains locked until the user completes the trade or withdraws LP shares, after which they can initiate another transaction to withdraw the BRC20 tokens.
Currently, BRC20 Swap operates in “black box” mode for security reasons—without consensus or formal verification, users can only withdraw funds up to the total amount deposited into the module. No user can withdraw more than the total locked assets.
Once users understand and consistently interact with the black box, and indexers gain confidence in its behavior, the system can transition from black box to “white box,” achieving consensus upgrades. Users can then freely deposit and withdraw assets.
Moreover, given that the BRC20 protocol and the broader Ordinals ecosystem remain in early stages, and UniSat holds dominant influence and reputation—providing comprehensive indexing services including transaction and balance queries—there is a risk of centralization. The modular architecture allows more service providers to participate, promoting greater decentralization of indexing.
BRC420
Developed by RCSV, the BRC420 protocol extends the original inscription model with recursive indexing, enabling more complex asset formats through recursive definitions. Additionally, BRC420 establishes constraints between usage rights and royalties. When users mint assets, they must pay royalties to creators. Owners can also allocate usage rights and set prices, incentivizing further innovation in the Ordinals ecosystem.
BRC420 opens broader possibilities for the inscription ecosystem—not only enabling complex metaverses through recursive referencing but also building smart contract systems via recursive code inscriptions.
ARC20
The ARC20 token standard is provided by the Atomicals protocol. Here, the “atom” is the fundamental unit, built upon Bitcoin’s smallest denomination—the sat. This means each ARC20 token is always backed by exactly one sat. Furthermore, ARC20 is the first token protocol to mint inscriptions or NFTs via Proof-of-Work (PoW), allowing participants to mine inscriptions directly in a process similar to Bitcoin mining.
Equating one ARC20 token to one sat brings several advantages:
1. First, the value of each ARC20 token will never fall below one sat, making Bitcoin serve as a “digital gold anchor.”
2. Second, transaction validation only requires querying the UTXO corresponding to the sat—contrasting sharply with BRC20’s reliance on off-chain ledgers and third-party sorters.
3. Additionally, all ARC20 operations can be completed entirely on the Bitcoin network, requiring no additional steps.
4. Finally, due to UTXO composability, direct exchange between ARC20 tokens and BTC is theoretically possible, opening future liquidity opportunities.
The Atomicals protocol sets special prefix parameters called Bitwork Mining for ARC20 tokens. Issuers can choose custom prefixes, and users must perform CPU mining to compute matching prefixes before gaining eligibility to mint the ARC20 token. This “one CPU, one vote” model resonates with Bitcoin purists.
Are Inscriptions Secure?
Inscriptions may appear as harmless text uploaded on-chain and parsed by centralized indexers, suggesting that security concerns are limited to centralized services. However, from a blockchain security standpoint, several issues warrant attention:
1. Increased Node Burden
Inscriptions increase Bitcoin block sizes, raising resource demands for nodes during block propagation, storage, and validation. Excessive inscriptions could reduce network decentralization, making it more vulnerable to attacks.
2. Reduced Security
Inscriptions can store any type of data, including malicious code. If malware is embedded in Bitcoin blocks, it could introduce security vulnerabilities.
3. Transaction Construction Required
Inscription transactions require careful construction and adherence to Ordinals’ FIFO rules to prevent disruption of inscription indexing.
4. Trading Risks Exist
Whether OTC or PSBT-based, inscription trading markets carry risks of asset loss.
Here are some specific security concerns:
1. Increased Orphan and Fork Rates
Larger blocks due to inscriptions increase orphan and fork rates. Orphan blocks are those not recognized by other nodes, while forks refer to competing blockchain versions. Both reduce network stability and security.
2. Attackers Tampering with Inscriptions
Attackers may exploit the openness of inscriptions to alter content.
For example, attackers could replace inscription data with malicious code, potentially compromising indexer servers or infecting user devices via trojans.
3. Improper Wallet Usage
If wallets are misused or unable to index inscriptions properly, users may accidentally transfer inscriptions, leading to asset loss.
4. Phishing or Fraud
Attackers may create fake UniSat or other indexer websites to trick users into conducting inscription trades and stealing their assets.
5. PSBT Signature Errors
Atomicals Market previously caused user asset losses due to incorrect signature methods.
Further Reading:<The Analysis of the Atomicals Market User Asset Loss>https://metatrust.io/company/blogs/post/the-analysis-of-the-atomicals-market-user-asset-loss
To address these security issues, the following measures can be taken:
1. Limit Inscription Size
Limiting inscription size reduces node burden. This is already being pursued by Luke, mentioned earlier.
2. Encrypt Inscriptions
Encrypting inscriptions helps prevent attacks involving malicious code.
3. Use Trusted Inscription Sources
Using trusted sources prevents phishing and signature-related issues.
4. Use Inscription-Supporting Wallets
Use wallets compatible with inscriptions for transfer activities.
5. Prioritize Code and Script Audits
With experimental protocols like BRC20-Swap and recursive inscriptions introducing code and scripts, ensuring their security is critical.
From technical and security perspectives, Bitcoin inscriptions are essentially a loophole exploiting existing rules. Taproot scripts were not designed for data storage, and thus carry inherent security risks. Luke’s modifications to Bitcoin Core code are technically sound from a security standpoint. He did not alter Bitcoin’s consensus layer directly but adjusted the Spam Filter (policy filter) module so nodes automatically discard Ordinals transactions upon receiving P2P broadcast messages. Within this policy filter, multiple isStandard() functions check whether transactions meet standard criteria. Non-compliant transactions are quickly dropped.
In other words, although Ordinals transactions can still eventually be included in the blockchain, most nodes will not add them to their mempools, increasing latency for miners willing to include such data. However, if a mining pool broadcasts a block containing BRC-20 transactions, other nodes will still recognize it.
Luke has already implemented policy filter changes in the Bitcoin Knots client and plans to introduce similar updates to Bitcoin Core. His modification introduces a new parameter, g_script_size_policy_limit, to restrict script sizes in multiple locations. This change imposes additional script size limits, affecting how transactions are accepted and processed.
Currently, the default value of this parameter is 1650 bytes. Any node client can override it at startup using the -maxscriptsize parameter:
Even with code updates, it will take considerable time before all miner nodes upgrade to the new version. During this period, innovators in the inscription community should have time to develop safer protocols.
Metatrust Labs has already integrated on-chain data and asset tracking into its metaScore platform, providing risk ratings and monitoring for inscription investments. Additionally, its metaScout platform features a rule engine for monitoring Bitcoin network activity, helping investors track real-time inscription data.
In this issue, we explored the technical foundations and potential security issues of the popular inscription ecosystem. Next time, we’ll dive into the more complex Taproot circuit etching technology—BitVM. Stay tuned.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
