Behind the Scenes of a Bitcoin Transaction.
Bitcoin was the first revolutionary digital currency which proved to the world that a payment system can exist on a peer-to-peer Decentralized System.
Bitcoin to the world is just a set of transactions, But is that it??
The Answer is an absolute NO!!, there is a lot more going on behind the scenes of a Bitcoin Transaction.
How are your Payment Logic coded into these transaction?? How does bitcoin work??
The answer to all is “Transaction Scripts”. Every single logic of your transactions are coded using a Scripting Language, and these coded logic’s are what we call, “Bitcoin Transaction Scrips”.
A Transaction Script is basically a list of instructions recorded with each transaction,which describes the way ,the next person can have access over the Bitcoin/Payment being transferred. A typical script for a Bitcoin transfer, to a particular Destination address is checked for spending based on 2 things:
- A publickey that when hashed,results in the address of the destination embedded in the script.
- A signature which verifies the public key provided and henceforth prove the ownership of the private key for the public key specified.
As we know a new transaction is valid in the chain only if the transaction scripts of its input field and the transaction script of its preceding transaction are validated as true.
InputTX: An inputTX is a reference to the previous transaction. A transaction may contain many such inputs and are nothing but the hash values of the previous transaction.For a new transaction the input values from the output of previous transaction are added and the total is used by the output of the new transaction. ScriptSig from the InputTx is the first half of the transaction Script and is called an Unlocking Script.
The ScriptSig contains two components, a signature and a public key. The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. The second component is nothing but an ECDSA signature over a hash of a simplified version of the transaction.The signature along with the public key is used to prove that the transaction is from the owner of the mentioned address only.
OutputTx: An OutputTx contains instructions for sending bitcoins. There can be more than one input,and they all share the value of the inputs.Since an output of a transaction can be referenced only once by a input,the combined input value also needs to be sent in the output if we don’t want to lose them. if the input value is worth 50BTC and the output is 10BTC,the bitcoin will create two transactions in which 10BTC is sent to the destination address and the remaining 40BTC back to you. ScriptPubKey is the second half of the transaction Script and is called locking Script.
ScriptSig : <Signature> <pubkey>ScriptPubKey : OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Verification of Scripts: The Scripting language used in Bitcoin is stack based,which means that each data,input or output is put on a stack of other data. The script of the OutputTx is executed first i.e the redeemer’s code and finally the inputTx is executed. The input’s ScriptSig and the referrenced outputs’s ScriptPubKey are evaluated and the input is said to be authorized if the ScriptPubKey returns True.
The Full Transaction Script looks like this:
<signature> <pubkey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGBitcoin mainly deals with two different pairs of ScriptSig/ScriptPubkey, corresponding to the two different types of transaction.
- Pay-to-PubkeyHash: This is the most common type of transaction seen in the Bitcoin chain.
The ScriptSig and ScriptPubkey in the Pay-to-Pubkeyhash transaction are:
ScriptSig : <signature><pubkey><signature> : Its a data which represents your digital signature done using the private key of your corresponding public key.<pubkey> : Its a data representing your publickey.ScriptpubKey : OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGOP_DUP[operation]: Duplicates the top stack item.OP_HASH160 [operation] : The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<pubKeyHash> : data which represents the hash of your publickey.OP_EQUALVERIFY[operation] : Returns 1 if the inputs are exactly equal, 0 otherwise.OP_CHECKSIG[operation] : Verifies digital Signature.
Steps of execution of the program:
- The output ScriptSig(unlocking Script) which is first executed are added on to the stack.
2. The input ScriptPubkey(Locking Script)is added to the stack. The operation OP_DUP duplicates the first element on the stack.
step executed in script:
OP_DUP OP_HASH <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
3. The operation OP_HASH160 hashes the first element on the stack .
step executed in script:
OP_DUP OP_HASH <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
4. <pubkeyhash> is a data and is added on to the stack.
step executed in script:
OP_DUP OP_HASH <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
5. The operation OP_EQUALVERIFY compares the first two elements of the stack,in reality it 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 elements if its true.if false it leaves it there.
step executed in script:
OP_DUP OP_HASH <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
6. In the final step,the signature on the stack is verified with OP_CHECKSIG operation wherein OP_CHECKSIG takes the first argument <pubkey> from the stack and validates the second argument <signature>. Basically it tries to open the <signature> with the public key <pubkey>. If it succeeds it returns true thus making the transaction OutputTx valid.
step executed in script:
OP_DUP OP_HASH <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG
Therefore in the Pay-to-PubkeyHash transaction,first we prove that the public key that the redeemer states is the same as we had in the InputTX ,then we verify if the redeemer has the right secret key by verifying the signature of the transaction.
A reallife Pay-to-PubkeyHash transaction in Bitcoin looks like:
wherein the “raw_scriptSig” is the ScriptSig(Unlocking Script) where the first 2 bits are the rawdata bits appended with the ScriptSig,followed by the <Signature>(3045…….01),which is followed by some 2 bits which represent the length of the public key i.e 21,which is then followed by the <publickey>.
“raw_scriptPubKey” is the ScriptPubKey(locking Script) of the transaction where 76 is the opcode value for OP_DUP,which is followed by a9 which is the opcode value for OP_HASH160, and that is followed by a 2 bit data that represent the length of the hash of the pubkey. The <pubkeyHash> is followed after the length which is further appended with 88 and ac which are the opcodes for OP_EQUALVERIFY and OP_CHECKSIG respectively.
2.Pay-to-Script-Hash(P2SH): Pay-to-Script-Hash(P2SH) transactions were standardized to allow transactions to be sent to a multisig addresses i.e to a scriptHash instead of a public-key-hash(for a particular destination address). To spend the Bitcoins that is sent via P2SH ,the recepient must provide a script(redeemScript) which matches the script hash and data,and evaluates the script as true.
In P2SH transaction ,the signature of several people involved in the multisig address is required to spend the bitcoins. m-of-n is type of multisig pubkey scripts ,where m is the minimum number of signatures which must match a public key; n is the number of public keys being provided. Both m and n are represented with opcodes OP_1 through OP_16, corresponding to the number desired.
A ScriptSig in the P2SH transaction contains signatures and redeemScript. RedeemScript is similar to Pubkey in function where one of its copy is hashed to create a P2SH address and the other copy is placed in the spending Signature Script.
The Script for the P2SH transaction involving a m-to-n multisig pubkey scripts looks like :
RedeemScript: M <pubkey1><pubkey2><pubkey3> N OP_CHECKMULTISIGScriptPubKey(lockingScript) : OP_HASH160 <redeemScript> OP_EQUALScriptSig(Unlocking Script) : <signature1><signature2><redeemScript>
The Steps in which the P2SH is executed:
- Similar to Pay-to-HashPubkey, the Output ScriptSig’s(Unlocking Script) data are added on to the stack.Before that a 0 is appended on to the stack because when the validation returns false all the data are popped from the stack and the 0 remaining on the stack represents the failure of the transaction.
2. The scriptPubKey(locking Script) is the pushed on to the stack.The operation OP_HASH160 hashes the First Element on the stack and puts it back on the stack.
step executed in script:
OP_HASH160 <redeemScript> OP_EQUAL
3. <redeemScript> is a data and is pushed on to the stack.
step executed in script:
OP_HASH160 <redeemScript> OP_EQUAL
4. The operation OP_EQUAL puts true on the stack if two elements are the same,and the top stack elements are removed if its True.
step executed in script:
OP_HASH160 <redeemScript> OP_EQUAL
5.In P2SH transactions the redeemScript is run after OP_EQUAL returns True.
Redeem Script:
M <publickey1><publickey2><publickey3> N OP_CHECKMULTISIG
6. The operation OP_CHECKMULTISIG,compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise.
Redeem Script:
M <publickey1><publickey2><publickey3> N OP_CHECKMULTISIG
The input of a OP_CHECKMULTISIG is “ x sig1 sig2 … <number of signatures> pub1 pub2 <number of public keys>”
A real-life example of a P2SH transaction looks like:
“raw_scriptSig” represents the ScriptSig of the P2SH transaction where the first two bit are the 0 pushed into the stack followed by a 2 bit raw data which is appended as a part of the transaction. Following the raw data the three digital signatures(underlined and starting with 3045) are appended to the transaction which is succeeded by the redeem Script.
The redeem script consists of three public keys which are preceded with their lenghts.
“raw_scriptPubkey” represents the ScriptPubKey of the P2SH transaction where the first two bit a9 corresponds to the opcode OP_HASH160 ,followed by length of hash and hash of the redeemScript which is succeeded by 87 which corresponds to the opcode OP_CHECKMULTISIG.
The Other Uncommon type of transactions in Bitcoin Network are:
- Provably Unspendable Transaction: This is Basically a null transaction in the most simplest form.
This type of transaction will always be invalid. Whatever code is in ScriptA,when ScriptB is executed the OP_RETURN opcode stops the execution of the transaction script and validates it as FALSE.
Thsi type of transaction is used to encode data in the blockchain.After the OP_RETURN you can insert arbitary data. The advantage of these transaction is that the simple bitcoin nodes can cut back the transaction saving memory.
- Anyone-Can-Spend Transaction : In these transaction the Output Script of the first transaction is empty,and hence a redeeming second transaction can be simply put TRUE on the stack and declare the transaction as valid.Arguably anyone can do this if they are lucky enough to find such empty transaction.
As of currently Anyone-Can-Spend Transaction are non-standard,and not broadcasted in the network.
- Generation Transaction : As we know a Bitcoin transaction is validated against the previous transaction. But when a miner passes the hashing exam and redeems his prize,there wont be any previous transaction. in such case he just simply creates an Input TX with the publicly known mining fee.And redeeming such transaction is allowed to anyone who can provide a valid signature of public key in the Input TX,which is miner himself.
The Transaction Script is : <signature> <pubkey> OP_CHECKSIG
Steps in which the Script is executed are:
- The program reads the first token <signature> and since it is a data it is pushed on to the stack ,similarly it pushes the next token <pubkey> onto the stack.
step executed in script:
<signature> <pubkey> OP_CHECKSIG
2. The operation OP_CHECKSIG takes the first argument <pubkey> and validates the second argument <signature>. If the validation is successful it returns TRUE thus making the transaction Output TX valid.
step executed in script:
<signature> <pubkey> OP_CHECKSIG.
It is to be noted that only the owner of the private key can Redeem the Generation Transaction and is a lucky miner!!!
Refer the below link to further understand ,Bitcoin Scripts with a use cases:
https://medium.com/@raksha.p82/a-case-of-bitcoin-transaction-scripts-be03acec2874
References:
- Programming Bitcoin Transaction Scripts by Roland Kofler.
- Bitcoin Scripts by Koshy.
