Working of a Bitcoin Transaction Script.

We know that all bitcoin transactions have scripts embedded into its inputs and outputs. And when a transaction is validated, the input scripts are concatenated with the output scripts and are evaluated.
But how exactly is it evaluated?? How does a Bitcoin Transaction work??

Let's Consider a Use Case of Bitcoin Transaction Script(P2SH Script) to understand how they work:

Case: A Buyer goes to the grocery store and needs to pay the cashier. He generates a Tx, signs it, and sends the Tx to Seller. Seller signs the Tx and broadcasts to the network.
— How is this partial signing done?

Answer: We use a P2SH transaction Script for the transaction between the Buyer and the Seller.

Why P2SH Script?
— -> The answer to the question for why a complicated P2SH Script instead of directly sending the Tx to the Seller is because the addresses of a Bitcoin are based on public/private ECDSA key pairs i.e each address is based on a single Private Key stored on a single machine. Anyone who knows the Private Key corresponding to an address on a machine can move the funds/transact, this creates a major Security Risk. MultiSig(P2SH) addresses are a solution/alternative for these security problems, wherein we require multiple private keys stored at different machines to move a fund or transact. This completely eliminates the single point of failure. Using a P2SH Script, a recipient would require the signatures of several people (private Keys on different machines) to spend or move the funds.

When a Buyer has to send a transaction to Seller, the Seller wants to receive that payment to a P2SH address. So Seller creates the redeemScript and then uses that to create a redeemScript hash, which is then encoded into a P2SH address.

In redeemScript, we specify that we want a 2-of-2 address and provide our 2 public keys(public keys of sender and cashier) to generate a P2SH address.
The outputs will be :

1. A redeemScript of the form:
   M <Person A’s pub key><Person b’s pub key> N <checkmultisig>
   where M and N are 2 as it is a 2-of-2 address.
2. A P2SH address which is nothing but a base58 encoding of the double hash of our redeemScript.

Now the Seller has the P2SH address he wants the Buyer to send his transaction to. And the Seller gives publishes his P2SH address to the Buyer and Buyer pays the Seller by sending a transaction(Input TX) to that multisig(P2SH) address containing his signature

Hence now the Buyer has paid by sending the money to the P2SH address, now for the Seller to spend that cash he has to create a transaction with an input whose scriptSig contains the redeemScript created earlier and his signature matching to the Public key included in the redeemScript. A Transaction typically looks like,

{
“vin”:[
{
“ScriptSig”:{ 
<signature of Seller><redeemScript>
}
],
“vout”:[
“addresses”: [ <P2SH address> ],
{
“ScriptPubKey”:{ <OP_HASH160> <redeemScriptHash><OP_EQUAL>
}
],
}

This is how the Partial Signatures are done.

Hence once the Seller sends a transaction containing his/her signature along with the redeemScript, We get the two signatures required to validate the redeemScript. And if redeemScript validates as true, the Transaction (payment) from Buyer to Seller is said to be valid/true. Once Valid, the Transaction is broadcast to the network(Chain) and the Seller can spend the transaction in his P2SH address.

Case2: A Buyer goes to the grocery store and needs to pay the cashier. But he wants to make his payment in installments and not at a single go. He generates a multiple Tx’s of installment, signs it, and sends the Tx’s to Seller.
— How to make sure Buyer pays back all his money on time?
— How will installment benefit Seller?
— How to keep track of the money repaid and money which still has to be repaid?
— What to be done if the Buyer pay’s back more money than he is supposed to? Will, he be repaid?? (and he has to be)

Answer: When a Buyer wants to pay the Seller, the Seller creates a RedeemScript and thereby creates a P2SH address and publishes it to the Buyer as an address where the transaction(money) is to be sent along with the RedeemScriptHash. And once a Buyer has this P2SH address, he sends the money by creating signed transactions(installments) and sends it to the P2SH address. And now the Seller can create a transaction with his RedeemScript and Signature and spend the money in the P2SH address.

Here Using the Bitcoin Transaction Script we can’t make sure if the Buyer has paid the money on time. We can get the money he has repaid(which might not be all which he owed) but we can’t have an incentive for the Buyer to pay all the money he owed on time. Even if we can have incentives like Reputation System or higher priority etc.., it has to be done external to the chain. A Bitcoin Script has no view of the output of a transaction as a design decision.

We also cant have any incentive for the Seller for having to pay him by installments, the incentive for Seller like Simple Interest over the capital etc. , has to be done externally to the chain.

Moreover, the transaction script can keep a track of money repaid to the Seller but it can’t keep the track of money yet to be repaid. This process will also have to happen externally.

And the Biggest problem is when a buyer does a transaction to the Seller owing more money than he supposed to. In this case, the Buyer cant reverse his transaction. In Bitcoin Chain, once a transaction has been submitted to the chain, it's unstoppable. Even if you want to cancel an unconfirmed transaction, you have to double spend the input of the transaction and therefore canceling the original transaction which is a very tricky and a bad way of dealing with the problem. Any other way the Buyer gets is amount back is if the seller spends the money and sends back to the Buyer, the excess money(which will be highly unlikely). Hence we can say that Bitcoin Transaction Scripts are not much help in realizing the above use case.

We can use the Ethereum Chain to effectively realize the above use case. Ethereum Chain provides a platform for smart contracts using which we can solve the problems of the use case. Smart contracts help you do a transaction in a transparent, conflict-free way while avoiding the services of a middleman. Smart Contract define rules and penalties around an agreement and automatically enforces the obligations.
In a smart contract, we can write code to incentify a Buyer to pay his money on time and at the same time maintain a record for the money he has repaid and the money he is yet to pay. We can incentify the Seller by setting up a simple Simple Interest Contract over the capital the Seller is owed over the period of time the Buyer repays. And most importantly in a contract, we can repay back the excess amount paid by the Buyer by mentioning the Buyers account address. So when a Buyer pay’s back to the Seller more than what he had owed, the excess amount can be returned back to the Buyer.

More Things to know about Bitcoin Transaction Scripts:

• All Bitcoin Transactions have scripts embedded into its inputs and outputs.
• The Scripts use a very simple programming language, which is evaluated from left to right using a stack.
• 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 being transferred. A typical script for a Bitcoin transfer, to a particular Destination address is checked for spending based on 2 things:

1. A public-key that when hashed, results in the address of the destination embedded in the script.

2. A signature which verifies the public key provided and henceforth prove the ownership of the private key for the public key specified.

• A new transaction is said to be 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.
• ScriptSig from the InputTx(preceding transaction)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 signature is nothing but an ECDSA signature over a hash of a simplified version of the transaction.
• ScriptPubKey from the Output Tx(current transaction) is the second half of the transaction Script and is called Locking Script. It contains a set of opcodes along with a Pubkeyhash which is the hash of the signed transaction corresponding to a particular public key.
• A full transaction script looks like:

ScriptSig : <Signature> <pubkey>
ScriptPubKey : OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Transaction Script:
<signature> <pubkey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

• Bitcoin mainly deals with two different pairs of ScriptSig/ScriptPubkey, corresponding to the two different types of transaction. The first type is the Pay-to-PubkeyHash. When a transaction of type Pay-to-PubkeyHash is to be validated, the input scripts and output scripts are concatenated and are evaluated. For a script to be valid, it should evaluate to true.basically an outputScript is a lock on how a transaction is spent and input Script acts as a key to open the lock and evaluate the output Script to true.
• What is done is that we first prove that the public key that the redeemer states is the same we had in the input TX, then we verify if the redeemer has the right secret key by verifying the signature of the transaction.
• The second type is 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 recipient 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 a 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 a 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_CHECKMULTISIG
ScriptPubKey(lockingScript) : OP_HASH160 <redeemScript> OP_EQUAL
ScriptSig(Unlocking Script) : <signature1><signature2><redeemScript>

• The Provably Unspendable Transaction is an uncommon type of transaction Bitcoin deals with. This is Basically a null transaction in the simplest form. This type of transaction will always be invalid. This type of transaction is used to encode data in the blockchain. The advantage of these transactions is that the simple bitcoin nodes can cut back the transaction saving memory.
• Anyone-Can-Spend Transaction is another type of transaction Bitcoin deals with. In these transactions 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.
• Generation Transaction is another Bitcoin 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 won't 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 the public key in the Input TX, which is miner himself.

Refer the below link for the detailed explanation on how the Transaction Scripts are evaluated using Stack :
https://medium.com/@raksha.p82/a-note-on-bitcoin-transaction-scripts-f04d298f1855

References:

• Programming Bitcoin Transaction Scripts by Roland Kofler.
• Bitcoin Scripts by Koshy.