Bitcoin’s original technology has always faced conflicts between widespread application and the capabilities Bitcoin should possess. Does widespread application and transaction volume imply more complex transaction instructions and larger transaction space? Does it mean that all functions must be implemented on the Bitcoin single system? In the early stages, these phenomena seemed to be issues with Bitcoin itself due to the underdeveloped ecosystem technology. With the advancement of technology, many of these issues will have clearer answers.
This article lists some related issues and the process of their emergence and resolution. Through this article, we can see the correlation between these issues and technology, as well as the changes in the Bitcoin main chain and related “test chains”. Bitcoin’s technology has always been explored by different projects and teams (including Ethereum, which is an exploration of Bitcoin’s imperfections), but the changes that occur on the Bitcoin mainnet have not been significant enough until the emergence of technologies such as Taproot, which has pushed the development to a new climax.
From an overall perspective, we can see the connection between these development processes and the related technologies, and speculate on more development directions and overall architectures.
1.1. Bitcoin’s Script Language and Multiple Instruction Deletions
Bitcoin’s programming language is a stack-based script language in reverse Polish notation, without loop statements and conditional control statements (later addressed by Taproot Script). Therefore, it is often said that Bitcoin’s script language is not Turing complete, which limits its capabilities.
Of course, due to these limitations, hackers cannot use this script language to write infinite loops (which would cause network paralysis) or malicious code that could cause DoS attacks, thus avoiding DoS attacks on the Bitcoin network. Bitcoin developers also believe that the core blockchain should not be Turing complete in order to prevent attacks and network congestion.
However, it is precisely because of these limitations that the Bitcoin network cannot run other complex programs and cannot perform some “useful” functions. In order to solve specific problems and meet user needs, subsequent blockchain systems directly changed this. For example, Ethereum’s programming language is Turing complete.
Common types of Bitcoin script instructions include:
Keywords:
1. Constants, such as OP_ 0, OP_FALSE.
2. Flow control, such as OP_IF, OP_NOTIF, OP_ELSE, …
3. Stack operations, such as OP_TOALTSTACK (pushes the input to the top of the alternate stack and removes it from the main stack), …
4. String operations, such as OP_CAT (concatenates two strings, disabled), OP_SIZE (pushes the string length of the top item on the stack without popping the element).
5. Bitwise logic operations, such as OP_AND, OP_OR, OP_XOR.
6. Arithmetic operations, such as OP_ 1 ADD (adds 1 to the input value), OP_ 1 SUB (subtracts 1 from the input value).
7. Cryptographic operations, such as OP_SHA1 (hashes the input using the SHA-1 algorithm), OP_CHECKSIG().
8. Pseudo keywords.
9. Reserved keywords.
Common types of Bitcoin script instructions include:
Scripts:
1. Standard transaction paying to a Bitcoin address (pay-to-pubkey-hash).
2. Standard transaction generating Bitcoin (pay-to-pubkey).
3. Provable unspendable/deletable outputs.
4. Anyone-Can-Spend outputs.
5. Puzzle transactions.
The five standard types of transaction scripts include: pay-to-public-key-hash (P2PKH), pay-to-public-key, multi-signature (limited to a maximum of 15 keys), pay-to-script-hash (P2SH), and data outputs (OP_RETURN).
1.2. Bitcoin Fork History, Reasons, and Significance
In the history of Bitcoin development, in addition to the issue of deleting instructions, there is also a dispute over block size, which often leads to Bitcoin hard forks.
At the beginning of BTC’s creation, there was no limit on block size in order to process the same number of transactions in the same amount of time. However, when the early BTC price was very low and the cost of malicious transactions was also very low, Satoshi Nakamoto hosted a soft fork on September 12, 2010, adding a temporary limit of 1 MB on block size. Nakamoto pointed out that this limit is temporary and can be gradually increased in a controlled manner in the future to meet scalability needs.
The following figure shows the history of Bitcoin forks:
With the popularity of Bitcoin, the issues of network congestion and increased confirmation time became more serious. In 2015, Gavin Andresen and Mike Hearn announced the implementation of BIP-101 in the new version of BitcoinXT, hoping to increase the block size limit to 8 MB. However, core developers such as Greg Maxwell, Luke Jr, and Pieter Wuille opposed this approach, believing that it would increase the threshold for running full nodes and bring uncontrollable effects. This debate eventually expanded in terms of the topics and participants involved.
From the above content, we can see that Nakamoto also expressed that “this limit on block size is temporary and can be gradually increased in a controlled manner in the future to meet scalability needs.” But when should a fork support larger blocks, and can a separate chain supporting large blocks solve the problem? In the ongoing controversy, numerous cases have emerged. For example, BCH initially had a block size of 8M, which later increased to 32M. BSV’s block size is 128M. In addition to BCH (and later BSV), many other BTC fork coins appeared during this period. According to BitMEX Research, at least 50 new fork coins emerged within a year after the BCH fork.
Later in this article, we will see that SegWit and Taproot on the Bitcoin mainnet have also increased the block space from 1M to 4M to some extent.
Bitcoin forks are a form of development exploration, attempting to support more needs through their own changes. These include user needs, miner needs, investor needs, developer needs, and more.
1.3. Several Typical Explorations in Bitcoin Development
After Nakamoto’s departure, Gavin Andresen led the establishment of Bitcoin Core and the Bitcoin Foundation. During this period, the exploration of BTC’s scalability has always existed, especially in the field of asset issuance.
(1) Colored Coins
Yoni Assia, CEO of eToro, first proposed the concept of colored coins in an article published on March 27, 2012. This idea continued to develop, and the concept of colored coins began to form and gain attention on forums such as Bitcointalk. Eventually, Meni Rosenfeld published a detailed whitepaper on colored coins on December 4, 2012.
The idea of colored coins is to represent broader assets and value by adding special labels (i.e., coloring) to specific parts of Bitcoin. Colored coins have appeared in a series of entities, roughly divided into two categories:
1) Based on OP_RETURN: For example, Open Assets proposed by Flavien Charlon in 2013 uses OP_RETURN (introduced in Bitcoin v0.9.0, which can be used to store a small amount of data on Bitcoin, originally limited to 40 bytes, later increased to 80 bytes). The opcodes are stored in the script and completed “coloring” and transactions through external reading. (This model is similar to how Ordinals rely on external indexing to determine the legitimacy of assets.)
2) Based on OP_RETURN: A typical example is the EPOBC Protocol proposed by ChromaWay in 2014. The additional information of EPOBC assets is stored in the nSequence field of Bitcoin transactions, and the category and legitimacy of each EPOBC asset need to be traced back to the genesis transaction to determine.
(2) MasterCoin (OMNI)
JR Willett published the concept of MasterCoin on January 6, 2012, and named it the “Bitcoin Second Whitepaper”, and officially launched the project through an ICO in July 2013, ultimately raising 5120 BTC (worth $500,000 at the time). MasterCoin differs from Colored Coins in that it establishes a complete node layer and maintains a state model database by scanning Bitcoin blocks. This database resides in nodes outside the blockchain. This design can provide more complex functions than Colored Coins, such as creating new assets, decentralized exchanges, and automated price feedback. In 2014, Tether also launched a stablecoin on Bitcoin through the Mastercoin protocol, known as Tether USD (OMNI).
(3) CounterParty
Counterparty was officially launched in 2014. Counterparty also uses OP_RETURN to store data in the BTC network. However, unlike colored coins, assets in Counterparty do not exist in the form of UTXOs but are transferred by loading information into transactions with specific data. When an asset holder signs a transaction with special data using the holding address, the asset is transferred. Through this method, Counterparty can achieve asset issuance, trading, and compatibility with Ethereum smart contracts.
In addition, some argue that Ethereum, Ripple, and BitShares also belong to the broader category of “Bitcoin 2.0”.
1.4. Bitcoin’s Imperfections and Layered Protocols
Bitcoin’s system imperfections (or limitations) mainly manifest in several aspects (the imperfections mentioned in this article are summarized based on the Ethereum whitepaper, and are not true imperfections).
1. Bitcoin’s UTXO Account System
In current blockchain projects, there are mainly two ways to store records: the account/balance model and the UTXO model. Bitcoin adopts the UTXO model, while Ethereum, EOS, and others adopt the account/balance model.
