# History of Bitcoin Programmability
Bitcoin has grown to become a more than trillion-dollar asset since its inception as the first decentralized peer-to-peer electronic cash system in 2008. Currently, it is about triple the size of Ethereum, the next largest-blockchain, with all others representing a mere fraction of the total blockchain asset market.
The sheer scope of Bitcoin adoption gives it unparalleled liquidity and security compared to other blockchains. Yet despite those advantages, its functionality has been relatively confined to digital currency for a number of reasons, including its …
* **Limited Scripting Language:** Bitcoin's scripting language, Script, is intentionally limited in its capabilities to ensure security and simplicity. It lacks the Turing completeness found in languages used by platforms like Ethereum, which restricts the types of logic and conditions that can be executed in Bitcoin smart contracts.\
* **Data and State Storage:** Bitcoin's blockchain is optimized for storing transaction data rather than the state information required by complex smart contracts. The lack of statefulness in Bitcoin's design makes it challenging to implement dynamic smart contracts that can interact and update according to varying conditions.
* **Execution Environment:** Bitcoin does not have a native execution environment that can run complex smart contracts. Platforms that support advanced dApps, like Ethereum, have a Virtual Machine (EVM) that provides a controlled environment for executing smart contracts.
For these reasons, most innovations in blockchain programmability have occurred on other chains over the past decade, namely, Ethereum. However, Bitcoin has increasingly proven its core promises of security and decentralization, while adding significant upgrades that are now paving the way for builders to add programmability.
The introduction of Segregated Witnesses (SegWit) in 2017 increased Bitcoin’s block size limit, while the Taproot upgrade in 2021 made it possible to batch signatures for validation, making it easier and faster to process transactions (unlocking atomic swaps, multi-signature wallets, and conditional payments). In 2022, developer Casey Rodarmor proposed his “[Ordinal Theory](https://rodarmor.com/blog/ordinal-theory/),” outlining a numbering scheme for satoshis that can place arbitrary data such as images, texts, and games onto Bitcoin transactions, forming the foundation for fully onchain NFTs on Bitcoin.
The innovation of ordinals expands Bitcoin’s utility to grow from a financial ledger into a fully functioning data ledger, with expanded data availability that opens up new possibilities for embedding state information and metadata directly on-chain, crucial for applications like smart contracts that require accessible and verifiable state data.
\
These developments have further enhanced the future of Bitcoin programmability, setting the stage for a new wave of decentralized applications to be built on the world’s most valuable blockchain.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://arch-network.gitbook.io/arch-documentation/history-of-bitcoin-programmability.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.