Bitcoin Smart Contracts: Truth Or Not?
Smart contracts are very popular in the cryptocurrencies environment. This is caused by several reasons. First of all, they have a bright and striking name. Even Ethereum founder Vitalik Buterin pointed out that it attracted too much attention. Second, they are a natural fusion of economic and IT grounding. Third, this term is really flexible and covers many different solutions.
Even without such a memorable name, these blockchain infrastructure elements are inevitable if you want to create a complex and universal solution. But there is an interesting thing: Bitcoin is commonly considered as a cryptocurrency without any special features. This is caused by misunderstanding and the lack of relevant data in the network. Most of existing information explains smart contracts in their high level functionality rather than in their technical details. A curious user will likely see that Bitcoin has something that allows creating smart contracts for it.
To be clear, at this point I quite regret adopting the term "smart contracts". I should have called them something more boring and technical, perhaps something like "persistent scripts".
— Vitalik Non-giver of Ether (@VitalikButerin) October 13, 2018
Buterin about smart contracts
Transaction Inputs and Outputs
We have already explained what each transaction consists of. Now it’s time to examine its input and output. Let’s begin with the output as it dictates the structure of the correspondent input. Each output has three parts: an assets value in satoshi, the length of the closing script, and the closing script itself. It is important to note that after the SegWit implementation (1, 2) this structure might be different. Still, we will describe it in an old-fashion way.
Output classic structure
When it comes to inputs, each of them refers to an output. It has more components inside, namely: TXID that points to a source transaction (the hash of a transaction); VOUT, which is an index number of the output; unlocking script size, unlocking script itself, and a currently unused sequence number intended to replace transactions with their newer versions. As it was mentioned before, some differences related to the SegWit implementation might be found here.
Input classic structure
Here, scripts are what we are looking for. Having two scripts united together, we will receive the result. The transaction input may unlock output funds or it may not. Either way, scripts will be checked and this is what we can call an ancestor of smart contracts.
All funds in each transaction have been protected with the help of code commands since the very beginning of Bitcoin. These commands are called “opcodes” or “functions”, and there is plenty of them described in details. Since 2009, some codes were disabled because of their potentially malicious influence. Others were introduced as a part of the BIP activation. In any case, they give a lot of freedom for programing complex conditions of transaction verification.
However, there are several rules. Probably, the main limitation is that the language used in the Bitcoin network (called Script) is not Turing complete. Such completeness requires many different conditions to be satisfied. In case of Script, it has no cycles and commands with repeating structures. Such an approach was taken as a precaution measure. It prevents nodes from entering endless computation cycles. Other rules explain how scripts operate with stack (memory component), what final output is considered valid, etc.
Since Script cannot have loops and cycles, it is definitely not “smart” in the way we understand this term. However, various solutions can be found in the contracts section of BitcoinWiki. The list contains the following solutions:
- “Smart” property. This concept ties the digital value specified in a unique way to the real estate or securities or any other valuable property.
- Transferable virtual property. Here, the digital value defines the ownership of some digital property like music, movie or painting.
- Autonomous software agents that can perform programmed vital functions to continue their operation.
- Distributed markets intended to perform blockchain-secured trading operations.
Some examples presented in the list include deposit, escrow, assurance, oracles implementation, cross-chain trading, multi-parties, micro-payments, external agents, etc. Even though the one-way nature of Turing incomplete functions prevents contracts from being fully operational, they are still able to provide different solutions.
Bitcoin smart contracts are not the only example of contracts applied as a pure transaction verification mean. A famous platform called Corda has the same purpose of its built-in code components. Different solutions that appeared after Bitcoin stepped up have different programing components as well. Some of them rely on their own software environment, like Ethereum with its Ethereum Virtual Machine (EVM). Others have no embedded code and plan to implement contracts as an upper-level solution (e.g. Nano). We will discuss them in the following articles.