Summary of new technological developments causing Bitcoin to surge again
TechFlow Selected TechFlow Selected
Summary of new technological developments causing Bitcoin to surge again
There has always been a conflict between the original Bitcoin technology and its ability to support large-scale applications.
Navigating Web3 tides with focused insightsAuthors: Fu Shaoqing, SatoshiLab, Wano Island BTC Studio
1. Main Explorations and Conflicts in Bitcoin's Original Technology
Bitcoin’s original technology has long faced conflicts between large-scale application demands and the inherent capabilities of the network. Does large-scale usage and transaction volume imply more complex transaction instructions and greater transaction space? Must all functionalities be implemented directly on a single Bitcoin system? In its early days, when the Bitcoin ecosystem was underdeveloped, these issues were often seen as intrinsic flaws of Bitcoin itself. As technology advances, many questions are now finding clearer answers.
This article outlines several key issues, their origins, and how they have been addressed. Through this analysis, we can observe the interplay between these challenges and technological evolution, as well as the transformation of Bitcoin’s main chain and related "test chains." Bitcoin's technology continues to be explored by various projects and teams—including Ethereum, which represents an exploration into Bitcoin’s limitations—though changes on the Bitcoin mainnet remained subtle until innovations like Taproot emerged, catalyzing protocols such as Ordinals and ushering in a new phase of development.
By examining this developmental trajectory and the technologies it produced, we can identify meaningful connections and make informed projections about future directions and architectural frameworks.
1.1. Bitcoin Script Language and Past Instruction Removals
Bitcoin uses a reverse-Polish notation scripting language without loop or conditional control statements (although Taproot and Taproot Scripts later expanded this capability). Therefore, it is commonly said that Bitcoin’s scripting language is not Turing-complete, resulting in certain functional limitations.
However, these limitations also prevent hackers from writing infinite loops—which could paralyze the network—or malicious code capable of launching denial-of-service (DoS) attacks. Thus, Bitcoin developers believe that the core blockchain should not be Turing-complete, to avoid potential attacks and network congestion.
Yet due to these same limitations, Bitcoin cannot execute other complex programs or perform many “useful” functions. Later blockchain systems, aiming to solve specific problems and meet user needs, directly addressed this issue—for example, Ethereum adopted a Turing-complete programming language.
Common Types of Bitcoin Script Instructions:
Keywords:
1. Constants: e.g., OP_0, OP_FALSE
2. Flow Control: e.g., OP_IF, OP_NOTIF, OP_ELSE, …
3. Stack Operations: e.g., OP_TOALTSTACK (pushes input to top of alternate stack, removes from main stack), …
4. String Operations: e.g., OP_CAT (concatenates two strings, disabled), OP_SIZE (pushes length of top stack element onto stack without popping)
5. Bit Logic: e.g., OP_AND, OP_OR, OP_XOR
6. Arithmetic Logic: e.g., OP_1ADD (adds 1 to input), OP_1SUB (subtracts 1 from input)
7. Cryptography: e.g., OP_SHA1 (hashes input using SHA-1 algorithm), OP_CHECKSIG()
8. Pseudo-operators
9. Reserved Keywords
Common Script Types:
Scripts:
1. Pay-to-public-key-hash (P2PKH) – standard Bitcoin address transactions
2. Pay-to-public-key – standard coin generation transaction
3. Provably unspendable / removable outputs
4. Anyone-Can-Spend outputs
5. Puzzle transactions
The five standard script types include: Pay-to-Pubkey Hash (P2PKH), Pay-to-Pubkey, Multisignature (up to 15 keys), Pay-to-Script Hash (P2SH), and data output via OP_RETURN.
Detailed explanations are available at: https://en.bitcoin.it/wiki/Script
Removal of Supported Bitcoin Instructions
Bitcoin has undergone multiple rounds of instruction removal throughout its history. The red sections in the diagrams below indicate removed instructions.
(1) String Operations
(2)
(3) Arithmetic Operations
Why were instructions removed? While security was one consideration, viewing this through the lens of layered design reveals deeper rationale—removing features simplifies the base protocol, making it more fundamental and stable. Perhaps Satoshi Nakamoto foresaw this; otherwise, he wouldn't have proactively removed instructions. Most people tend to design small systems that directly satisfy user needs with full functionality, rather than building collaborative large-scale protocols.
This leads to an important observation: only Bitcoin is truly suitable as a Layer 1 network. As discussed in my article “Will High Bitcoin Prices Lead to a New Alternative Chain?”, there may be economic and technical possibilities for alternative chains. However, given Bitcoin’s fundamental characteristics and its suitability for layered architecture, almost no other chain can serve as true Layer 1 infrastructure. Any so-called alternatives would at best be 1.5-layer constructs. At the Layer 1 level, Bitcoin is the authentic product—any substitutes are merely knockoffs.
1.2. Bitcoin Fork History, Causes, and Significance
Throughout Bitcoin’s development, apart from instruction pruning, another major source of contention has been the block size debate, frequently leading to hard forks.
When BTC was first created, there was no block size limit, allowing for higher transaction throughput per unit time. But during Bitcoin’s early years, when prices were low, the cost of spamming the network was minimal. To counteract abuse, Satoshi Nakamoto led a soft fork on September 12, 2010, introducing a 1 MB cap on block size. He noted this limitation was temporary and could be gradually increased in a controlled manner to accommodate scaling needs.
Below is a diagram showing Bitcoin’s fork history:
As Bitcoin gained popularity, network congestion and longer confirmation times became increasingly severe. In 2015, Gavin Andresen and Mike Hearn announced support for BIP-101 in a new version of BitcoinXT, proposing to raise the block limit to 8 MB. Core developers including Greg Maxwell, Luke Jr, and Pieter Wuille opposed this move, arguing it would increase the barrier to running full nodes and introduce uncontrollable side effects. This debate eventually broadened in both scope and intensity.
As mentioned earlier, even Satoshi acknowledged the block size limit was temporary and subject to gradual increases over time. But when should a fork occur to support larger blocks? Can splitting off a separate chain with larger blocks solve the problem? Amid ongoing disputes, numerous examples emerged. For instance, BCH started with an 8 MB block size, later increasing to 32 MB. BSV supports 128 MB blocks. Besides BCH (and later BSV), many other BTC forks appeared during this period. According to BitMEX Research, at least 50 new forked coins emerged within a year after the BCH split.
Later sections will show that SegWit and Taproot upgrades on the Bitcoin mainnet effectively increased block capacity from 1 MB to 4 MB.
Bitcoin forks represent exploratory developments, testing whether internal modifications can better support growing demand. These reflect diverse interests: users, miners, investors, developers, etc.
1.3. Key Explorations in Bitcoin’s Development
After Satoshi’s departure, his successor Gavin Andresen founded Bitcoin Core and the Bitcoin Foundation. During this time, scalability research continued, especially in asset issuance.
(1) Colored Coins
Yoni Assia, CEO of eToro, first introduced colored coins in an article published March 27, 2012. The concept evolved further on forums like Bitcointalk, culminating in Meni Rosenfeld’s whitepaper detailing colored currency on December 4, 2012.
Colored coins aim to represent broader assets and values by tagging specific fractions of Bitcoin. Implementation approaches fall into two categories:
1) Based on OP_RETURN: Open Assets, proposed by Flavien Charlon in 2013, used OP_RETURN (introduced in Bitcoin v0.9.0 to store small data amounts, initially limited to 40 bytes, later raised to 80 bytes). Data is stored in scripts and externally indexed to achieve coloring and transfer mechanisms (similar to how Ordinals use external indexing to verify asset legitimacy).
2) Based on nSequence Field: ChromaWay’s EPOBC Protocol (2014), which stores additional asset information in Bitcoin’s nSequence field. Asset type and validity must be traced back to genesis transactions.
(2) MasterCoin (OMNI)
JR Willett introduced the idea of MasterCoin on January 6, 2012, calling it the “second whitepaper of Bitcoin.” The project officially launched via ICO in July 2013, raising 5,120 BTC (worth $500,000 at the time). Unlike Colored Coins, MasterCoin built a complete node layer that scanned Bitcoin blocks to maintain an off-chain state database. This allowed more advanced features like issuing new assets, decentralized exchanges, and automated price feeds. In 2014, Tether launched its USD stablecoin (USDT) on the Mastercoin protocol, known as OMNI USDT.
(3) Counterparty
Launched in 2014, Counterparty also used OP_RETURN to embed data into the BTC network. However, unlike colored coins where assets exist as UTXOs, Counterparty assets are transferred via signed transactions containing special metadata in OP_RETURN fields. This approach enabled asset issuance, trading, and even platforms compatible with Ethereum-style smart contracts.
Some also consider Ethereum, Ripple, and BitShares part of a broader “Bitcoin 2.0” movement.
1.4. Bitcoin’s Imperfections and Layered Protocols
Bitcoin’s perceived imperfections—or limitations—are summarized here based on insights from the Ethereum whitepaper, though these may not be true flaws.
1. Bitcoin’s UTXO Account Model
In current blockchain systems, two primary models record account states: account/balance model and UTXO model. Bitcoin uses UTXO; Ethereum, EOS, and others use account/balance.
In Bitcoin wallets, users typically see balances, but in Satoshi’s original design, there is no balance concept. “Bitcoin balance” is derived by wallet software. UTXO (Unspent Transaction Output) is central to transaction creation and validation. Transactions form a chain structure—all valid transactions trace back to prior outputs, ultimately rooted in mining rewards and ending with unspent outputs.
So in reality, there is no such thing as Bitcoin—only UTXOs. Each Bitcoin transaction consumes inputs and creates outputs. These outputs become UTXOs—the unspent results of past transactions.
Implementing smart contracts under the UTXO model presents significant challenges. Gavin Wood, designer of the Ethereum Yellow Paper, deeply understood this. Ethereum’s key innovation was smart contracts. Implementing Turing-complete smart contracts atop UTXO proved difficult. In contrast, the account model is naturally object-oriented—each transaction updates a corresponding account (e.g., incrementing nonce). To simplify management, a global state is maintained, updated with every transaction—a model analogous to real-world dynamics where every minor change alters the whole. Hence, Ethereum adopted the account model, and most subsequent public chains followed suit.
Another serious drawback of UTXO is the lack of fine-grained withdrawal controls per account, as noted in the Ethereum whitepaper.
2. Bitcoin’s Script Language Is Not Turing-Complete
While Bitcoin’s script language supports various computations, it lacks loops and conditional statements. Thus, it is not Turing-complete, imposing certain limitations. On the flip side, this prevents infinite loops that could stall the network or enable DoS attacks. Developers argue the core blockchain shouldn’t be Turing-complete to avoid vulnerabilities and congestion. However, these very limitations prevent Bitcoin from running complex programs. Loop restrictions exist primarily to prevent infinite loops during transaction validation.
Using non-Turing-completeness for security alone is insufficient reasoning. Non-Turing-complete languages are inherently limited in what they can express.
3. Other Bitcoin Limitations: Security and Scalability
Mining centralization remains a concern. Bitcoin mining involves repeatedly modifying block headers until a hash below the target is found. This process is vulnerable to two forms of centralization. First, ASICs (Application-Specific Integrated Circuits) designed specifically for Bitcoin mining offer thousands-fold efficiency gains, meaning mining is no longer egalitarian but requires massive capital investment. Second, most miners no longer validate blocks locally—they rely on centralized mining pools for block headers. This is critical: currently, the top three mining pools collectively control about 50% of Bitcoin’s hashing power.
Scalability is another major challenge. Bitcoin grows by ~1 MB per hour. If it processed Visa’s 2,000 transactions per second, it would grow by 1 MB every three seconds (~1 GB/hour, ~8 TB/year). Even lower throughput causes community debates—larger blocks improve performance but increase centralization risks.
From a product lifecycle perspective, some of Bitcoin’s shortcomings could be improved within the existing system, albeit constrained by legacy architecture. But if a new system is being built, those constraints vanish. When designing a new blockchain, these enhancements can be incorporated from the start.
Layered Design
Layered design is a methodology for managing complex systems—dividing them into hierarchical layers with defined interfaces and responsibilities—to enhance modularity, maintainability, and scalability, thereby improving design efficiency and reliability.
For large, complex protocol stacks, layering offers clear benefits: easier comprehension, modular implementation, and incremental improvement. A classic example is the ISO/OSI seven-layer model, though practical implementations like TCP/IP merge layers into four. Advantages include independence between layers, flexibility, structural separation, ease of implementation and maintenance, and promotion of standardization.
Viewed through a layered protocol lens, Bitcoin’s traits—UTXO model, non-Turing-completeness, long block intervals, small block sizes, founder disappearance—are not flaws but essential characteristics of a foundational Layer 1 network.
Note: The author provides a detailed explanation of protocol layering in “A Guide to Bitcoin Layer 2 Infrastructure V1.5.”
2. Important New Technologies in Bitcoin Development (Block and Capability Expansion)
In the previous section, we examined Bitcoin’s original technical conflicts and exploratory cases, many of which led to hard forks or entirely new heterogeneous chains. Yet on Bitcoin’s own blockchain, similar explorations yielded valuable outcomes—essentially block expansion and capability enhancement—manifested in several ways.
2.1. OP_RETURN
Bitcoin developers have long sought to expand Bitcoin’s capabilities in various ways:
(1) Use of OP_RETURN
OP_RETURN is a script opcode used to terminate script execution and return the top stack value—akin to a return statement in programming languages. Historically, OP_RETURN’s function has evolved significantly. Today, it primarily serves as a mechanism to store arbitrary data on-chain.
Originally intended to prematurely end script execution, returning the stack top, OP_RETURN had a vulnerability quickly patched by Satoshi.
Further Changes to OP_RETURN Functionality
In Bitcoin Core v0.9.0, “OP_RETURN outputs” became a standard output type, allowing users to attach data to “unspendable transaction outputs.” Initially capped at 40 bytes, this limit was later raised to 80 bytes.
Storing Data on the Blockchain:
Changing OP_RETURN to always return false had an interesting consequence: since no opcodes or data after OP_RETURN are evaluated, users began exploiting it to store arbitrary data.
During the Bitcoin Cash (BCH) era (August 1, 2017 – November 15, 2018), the data limit attached to OP_RETURN outputs was extended to 220 bytes, enabling innovative applications such as posting content on blockchain-based social media.
On BSV, the 220-byte limit persisted briefly. Then in January 2019, because OP_RETURN terminates scripts without validating subsequent opcodes, nodes do not check whether scripts exceed the 520-byte maximum. Node operators thus decided to raise the max transaction size to 100 KB, giving developers more freedom for innovation—allowing larger, more complex data to be written to the BSV ledger. One notable example involved embedding an entire website into the BSV blockchain.
Although OP_RETURN expands functionality somewhat, its capabilities remain limited. This led to the development of Segregated Witness (SegWit).
(2) SegWit (Segregated Witness)
Segregated Witness (SegWit), proposed by Pieter Wuille (Bitcoin Core developer and co-founder of Blockstream) in December 2015, later formalized as BIP 141, modifies Bitcoin’s transaction data structure to address several issues:
1) Transaction malleability.
2) SPV proofs can omit signature data, reducing Merkle proof size.
3) Effectively increases block capacity.
The first two improve security and performance. The third—effective block size increase—had the greatest impact on future tech, laying groundwork for Taproot (SegWit version 2).
Although SegWit effectively increases block capacity, it still faces limits. The original block size cap is 1 MB. Since witness data isn’t counted toward this limit, abuse must be prevented—thus a total block weight limit was introduced.
Block Weight = Base Size * 3 + Total Size
Base Size: block size excluding witness data
Total Size: serialized transaction size (in bytes) including base and witness data per BIP 144
SegWit imposes a block weight limit ≤ 4 million weight units (MWU).
SegWit also technically enables Lightning Network scaling, though details are beyond this article’s scope.
(3) Taproot – SegWit Version 2
If you hear “Taproot” and think it’s a brand-new concept, realize it’s actually SegWit version 2—this clarifies its relationship to prior upgrades. Related BIPs are 340, 341, and 342: BIP 340 (Schnorr Signatures for secp256k1), BIP 341 (Taproot: SegWit version 1 spending rules), BIP 342 (Validation of Taproot Scripts).
In November 2021, Taproot activated via soft fork, combining BIPs 340, 341, and 342. BIP 340 introduced Schnorr signatures, replacing ECDSA, enabling batch verification and enhancing privacy and scalability—opening doors for complex smart contracts. BIP 341 implemented Merklized Abstract Syntax Trees (MAST) to optimize on-chain transaction storage. BIP 342 (Tapscript) enhanced Bitcoin’s native scripting capabilities.
The capacity expansion brought by SegWit and Taproot enabled Schnorr, MAST, and Taproot Scripts—technologies aimed at expanding Bitcoin’s mainnet functionality.
2.2. Schnorr, MAST, Taproot Scripts
From Section 2.1, we see Bitcoin’s continuous efforts in block and capability expansion, culminating in Taproot and associated technologies—Schnorr, MAST, and Taproot Scripts—that truly unlocked Bitcoin’s potential.
(1) Schnorr Signatures
Taproot required improvements in signature schemes, leading to the adoption of Schnorr signatures over ECDSA. Schnorr signatures are a digital signature scheme offering efficient, secure signing of transactions and messages. First described by Claus Schnorr in a 1991 paper, they are praised for simplicity, provable security, and linearity.
Advantages of Schnorr Signatures:
1) Offers efficiency, enhanced privacy, retains all ECDSA features and security assumptions. Enables smaller signatures, faster verification, and better resistance to certain attacks.
2) Most notable feature: key aggregation—multiple signatures can be combined into one valid for the sum of public keys. Multiple parties can jointly generate a single signature.
Key aggregation reduces fees and improves scalability—multisig signatures occupy the same space as single-signature ones. This shrinks multisig payments and related transactions like Lightning Network channel operations.
3) Schnorr signatures provide strong immutability guarantees.
4) Enhanced privacy: multisig setups appear identical to single-key transactions, making it harder for observers to distinguish between single and multi-party spending. In n-of-m multisig, it’s harder to determine which participants signed a transaction.
Schnorr signatures were implemented in BIP-340 as part of the Taproot upgrade, activating at block height 709,632 on November 14, 2021. They make BTC signatures faster, more secure, and easier to handle. Importantly, Schnorr is backward-compatible cryptographically, enabling deployment via soft fork.
(2) MAST – Merklized Abstract Syntax Tree
There is slight ambiguity in the acronym MAST. Official BIP documents (e.g., BIP 114) and some articles define MAST as Merklized Abstract Syntax Tree. Others use Merklized Alternative Script Trees, translating to Chinese as “Merklized Alternative Script Tree (MAST).” In the book *Mastering Bitcoin* and certain articles (e.g., https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade), this latter definition appears.
Functionally, both concepts seem equivalent. From a translation standpoint, I prefer adhering to the official BIP documentation.
MAST combines two ideas: Abstract Syntax Trees (AST) and Merkle Trees.
An AST comes from compiler theory and formal linguistics. It is an intermediate representation in compilation, structuring source code semantically as a tree—each node representing a semantic unit, edges showing relationships. ASTs help compilers analyze, optimize, and generate target code. Informally, an AST breaks down a program into manageable parts, easing analysis and optimization. Generating an AST involves linking equations and premises with arrows until all dependencies are mapped. Below is an example AST for a script.
On the other hand, Merkle Trees allow verifying whether an element belongs to a set without revealing the entire set. For example, Bitcoin’s SPV wallets use Merkle trees to confirm a transaction’s presence in a block without downloading the full block, saving bandwidth.
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
Waterdrip Capital
