This post is also in issue 18.
Every Bitcoin transaction runs a small program that describes under which conditions the transaction is valid. This surprising behavior can be exploited to construct a variety of contracts on top of bitcoin. In this article you will learn how basic transaction scripts work in principle.
A new transaction is valid if the transaction scripts of its own input field and the transaction script of its predecessing transaction validates to true.
Figure: An output tx is valid only if a script program results in a boolean TRUE. The script is composed of two scripts blocks; the execution order of the scripts is: first ScriptA from OutputTX is executed, then ScriptB from InputTX.
The scripting language is stack-based, this means that each data, input or output is put on a stack of other data. The script of OutputTX is executed first: i.e. the redeemer’s code. But it is not possible to stop the script before it is executed entirely and marking the transaction as valid. Finally the InputTX scriptB is executed and when the program terminates its return value determines if the OutputTX is considered valid.
Provably Unspendable Transaction
The null transaction, probably the simplest one.
This transaction will always be invalid. Whatever code is in ScriptA, when ScriptB is executed, the OP_RETURN op-code stops the execution of the transaction script and validates to FALSE. This pattern is often used to encode data in the blockchain. After the OP_RETURN you can insert arbitrary data. The advantage is that the simple bitcoin nodes can prune the transaction, saving memory, while full nodes will hold it. This is considered good behavior when ‘misusing’ the blockchain for storing data.
If the outputscript of the first transaction is empty, a redeeming second transaction can simply put TRUE on the stack so that the transaction is valid. Arguably anyone can do this if he is lucky to spot such an ‘empty’ transaction. Anyone-Can-Spend are currently non-standard, and not broadcasted in the network. But they can play an important role in future, for example with Fidelity Bonds.
Normally a Bitcoin transaction is validated against the previous transaction (the input transaction). When a miner wins in the hashing competition and redeems his prize, there is no previous transaction. He then simply creates an Input TX with the publicly known mining fee. Redeeming such a transaction is allowed to anyone who can provide a valid signature of the public key in the Input TX, i.e. the miner himself.
Now it is time to execute the script step by step. Remember that a transaction script is executed on a stack. At the beginning the stack is empty and the program is:
<signature> <pubKey> OP_CHECKSIG
First the program reads the first token <signature> and since it is data, it puts it on the stack. <signature> should be a piece of data encrypted with the private key of the authorized redeemer.
Now the second token is also data, so we put <pubKey> on the stack. <pubKey> is the public key (the unhashed bitcoin address) of the redeemer. At the end of these two operations the stack looks like this:
The next token is an operation. OP_CHECKSIG takes the first argument <pubKey> from the stack and validates the second argument <signature>. Basically it tries to open <signature> with the public key <pubKey>. If it succeeds it returns true, thus making the transaction Output TX valid.
We have seen: only the owner of the private key can redeem the Generation Transaction, he is the lucky miner.
The standard transaction script looks like this:
Therefore the full script looks like this:
<signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Let’s step through the execution of the program:
The two data tokens are put on the stack in the first two steps of the program
The operation OP_DUP duplicates the first element on the stack, so that we get:
The operation OP_HASH160 hashes the first element on the stack, so that we get:
<pubKeyHash> is put on the stack:
The operation OP_EQUALVERIFY compares the first two elements of the stack, in reality this is a composed operation: OP_EQUAL and OP_VERIFY are executed. OP_EQUAL puts TRUE on the stack if the two elements are the same. OP_VERIFY marks a transaction valid, if the top stack element is true, and removes the top stack element if its TRUE, if it’s false it leaves it there.
Generally a command executed on the stack takes its parameters from the stack, and puts its result at the stack. So OP_VERIFY behaves normally if it’s FALSE, because it leaves the result on the stack, but it behaves abnormally when it’s TRUE. It removes the result TRUE from the stack to continue with the next parameters.
The result of a positive validation is therefore:
Finally the signature on the stack is verified with OP_CHECKSIG in the same way as in the Generation Transaction. TRUE is returned if the check succeeds.
The simple transaction therefore is not so simple at all. First we prove that the public key that the redeemer states is the same as we had in the Input TX, than we verify if the redeemer has the right secret key by verifying the signature of the transaction.
In this article we have learned that a transaction script is composed of the payer’s input script and the output script of the predecessing transaction. The script needs to validate to TRUE for the transaction being considered valid. We have seen how a script is executed step by step.
With this knowledge at hand we can learn about more advanced contracts like multisig, escrow and smart property.
Description of opcodes and details of the scripts: https://en.bitcoin.it/wiki/Script
Some advanced transaction scripts: https://en.bitcoin.it/wiki/Contracts
Technical Introduction to Bitcoin: youtube.com/watch?v=Lx9zgZCMqXE
How the bitcoin protocol actually works: michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works
Vitalik Buterin’s bitcoin programming intro:
The post Thinking in Transactions appeared first on Bitcoin Magazine.
The BlueCoin Phenomenon
BlueCoin is very serious about their chosen theme. Taking cue from the cultural antics of the Dogecoin community, the founders of BlueCoin have been trying to give it something of a personality. They announced an official BlueCoin afterparty to ...read more
Ripple Labs CTO Designs Smart Contracts
Stefan Thomas is one of the more talented and respected developers in the space. An old hat at this young technology, he has been making waves as the CTO of Ripple labs. In a recent effort he has set ...read more
American court stops Mt. Gox from auctioning Bitcoin domain
A United States court issued a temporary order to forbid the sale of the domain Bitcoins.com, which is still owned by the CEO of the defunct cryptocurrency exchange Mt. Gox. Mark Karpeles announced the auctioning of the domain two weeks ago. The injuction ...read more
New York-based Coinsetter evolves to “full US Bitcoin exchange”
Following the recent presentation of the first BitLicense draft, the Bitcoin-related set of rules that will regulate the crypto-economy in New York, the local exchange Coinsetter announced its evolution from beta stage to “full US Bitcoin exchange”. “Today, we’re pleased ...read more
Building a Bitcoin Economy: How to Close the Loop
This guide is a continuation of a previous article at http://bitcoinmagazine.com/13104/building-bitcoin-economy-stimulate-adoption/ If you or someone in the area has been preaching crypto for a while, you probably have a few nearby businesses accepting Bitcoin by now. This is an important first ...read more
#OffTheCouch: Award-winning Film Could Bring Bitcoin to 1,000 High Schools
The Corporation Film’s Crypto Challenge from Hello Cool World on Vimeo. For its 10th year anniversary, “The Corporation” is raising money for a re-release shown to 1,000 schools across North America. Their original fiat campaign closed at $30,000, and they’re ...read more