Did you know that bitcoin uses a scripting system internally to create transactions? If so, then consider the next couple of sentences a review. Bit coin scripting is a simple programming language that is stack-based and processed from left to right. This means that each data, input or output is put on a stack of other data.
This language is to ensure that scripts will be executed in a specified time period and how users spend coins. In other words, a script is basically a set of instructions.
For bitcoins to transfer, according Bitcoin Wiki, from one address to another, the following must be supplied by the spender;
- a public key that, when hashed, yields destination address D embedded in the script, and
- a signature to show evidence of the private key corresponding to the public key just provided.
Bitcoin Wiki goes on to say that, “Scripting provides the flexibility to change the parameters of what’s needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.”
Transactions are validated “if nothing in the combined script triggers failure and the top stack item is true (non-zero).” This means that “the party who originally sent the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).”
Scripts are created by using the five following script types;
- Pay to Public Key Hash (p2pkh) is the most commonly used script that is used to pay a bitcoin address.
- Pay to Public Key (p2pk) are more secure and simplified versions of the p2pkh, but aren’t used that frequently.
- Also, Pay to Multisig (p2ms) allows users to share control of bitcoins between several keys.
- Pay to Script Hash (p2sh) are scripts that contain a script called redeemScript. To spend these coins “the spending transaction must provide a script matching the script hash and data which makes the script evaluate to true.”
- Data outputs are used to push data into the blockchain. Up to 40 bytes are allowed.
Henrique Barcelos adds in his Ethereum White Paper that;
“Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like “this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me”, essentially allowing decentralized cross-cryptocurrency exchange.”
Besides transferring money from one party to another, scripts have the potential to automatically unlock Wills when the heirs all agree that their loved one has passed, without the need of a lawyer. How about having mortgages, allowances, or crowdfunding campaigns that pay out whenever? What if they are instantly paid out when all parties approve a transaction? How about using an electric car for automobiles that won’t turn the vehicle until both parties are satisfied?
Script Limitations and How to Improve Scripts
Despite the potential that scripts offer the bitcoin community and beyond, there are a number of limitations. As these are addressed, the system will greatly improve.
Barcelos believes that the areas that the need to most improvement are;
Lack of Turing-completeness
Barcelos argues that bitcoin scripting language does not support everything, specifically loops. The reason for this is to prevent “infinite loops during transaction verification.” However, programmers can stimulate any loop they want by “repeating the underlying code many times with an if statement.”
Value-blindness
“There is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn”. This means that that a “powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B”. By doing so, an oracle can then determine the value of 1 BTC in USD. To achieve this, however, you would have to use the “inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B”.
Lack of state
UTXO, for example, do not allow multi-stage contracts or scripts. This makes “multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols” a challenge. Currently, UTXO can only be used for simple, one-off contracts.
Blockchain-blindness
Scripts, such as UTXO, are also blind to blockchain data like nonce and previous block hash. Because of this, applications in areas like gambling are limited.
Barcelos concludes that scripts can be improved by “building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin.”
The Problem
The problem with relying on the blockchain is that it is expensive in terms of development time, bootstrapping efforts, and security, while scripting is “is easy to implement and standardize,” but is limited in its capabilities and meta-protocols.
That’s why there is a need to construct a meta-protocol. This would be the public blockchain platform featuring smart contacts functionality known as Ethereum.
Barcelos says that with Ethereum “we intend to build an alternative framework that provides even larger gains in ease of development as well as even stronger light client properties, while at the same time allowing applications to share an economic environment and blockchain security.”
