This post originally appeared on Medium as part of a two-part series on Bitcoin smart contracts vs Ethereum smart contracts, and we republished with permission from Xiaohui Liu. Read part 1 here.
Why Ethereum is never needed
The entire reason for Ethereum’s existence is to overcome Bitcoin scripting language’s “limitations”. There are four limitations listed in the Ethereum whitepaper. We analyze each of them and show all claims of the supposed limitations are false, calling its existence into question.
Lack of Turing-completeness
while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops.
Contrary to popular belief, Bitcoin is Turing complete. Not only are there peer-reviewed theoretical¹ proofs², but it is also empirically verified on the Bitcoin blockchain³.
One common misconception lies in that Bitcoin script is a low-level instruction set (a.k.a., opcodes) of a virtual machine. It does not need looping instructions in itself. Loops can and should be constructed at higher level, just like all modern programming languages. It has been constructed in high-level programming language sCrypt. If the same logic is applied to the Ethereum Virtual Machine, it is also Turing-incomplete since there is no loop in its opcodes. So is Java, since its virtual machine JVM also lacks loop opcodes, which is obviously false because Java is known to be Turing complete.
Other ways of looping in Bitcoin include chaining transactions and payment channels.
Value-blindness
there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn.
There IS a way for a UTXO script to fully control the amount to be withdrawn at any granularity, using a technique called OP_PUSH_TX. It allows a script to access the amount in its UTXO and to specify how it could be spent into various outputs. There are scripts/contracts already developed to only allow certain amount to be withdrawn such as this one.
Lack of state
there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that.
There are ways to maintain internal state in a Bitcoin contract, using OP_PUSH_TX. There are many multi-stage contracts developed such as Tic-Tac-Toe⁴ and auction.
This is analogous to how functional programs keep state. Even though all functions are pure and stateless, mutable states can still be built atop using abstractions such as State monad. Bitcoin Script/UTXO, which is stateless itself, implements states similarly.
Blockchain-blindness
UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash.
There is a strong reason for Bitcoin UTXO/Script to not allow access to blockchain data: security. If Script can access external information, an attacker can manipulate this information to gain unfair advantages. Ironically, it is exactly these kinds of vulnerabilities that enabled many attacks on Ethereum such as SWC-116 and SWC-120, which is impossible on Bitcoin.
[1] Craig S. Wright: A Proof of Turing Completeness in Bitcoin Script. IntelliSys (1) 2019: 299–313
[2] Craig S. Wright: Bitcoin: A Total Turing Machine. IntelliSys (1) 2019: 237–252
[3] Bitcoin script is Turing Complete: sCrypt’s ‘Game of Life’ is Proof
[4] Play Tic-Tac-Toe on Bitcoin: https://scrypt.io/tic-tac-toe
New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.