Bitcoin Scripts & Application of Bitcoin Scripts

Bitcoin Scripts

                                      Bitcoin uses a scripting system for transactions. Script is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide

1. a public key that, when hashed, yields destination address D embedded in the script, and
2. a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins.

Applications of Bitcoin Scripts

                                                           There are many applications of bitcoin scripts few of the are explained below.

      1. Escrow transactions  ​​ 

                                                          Say Alice and Bob want to do business with each other — Alice wants to pay Bob in Bitcoin for Bob to send some physical goods to Alice. The problem though is that Alice doesn’t want to pay until after she’s received the goods, but Bob doesn’t want to send the goods until after he has been paid. What can we do about that? A nice solution in Bitcoin that’s been used in practice is to introduce a third party and do an escrow transaction.
Escrow transactions can be implemented quite simply using MULTISIG. Alice doesn’t send the money directly to Bob, but instead creates a MULTISIG transaction that requires two of three people to sign in order to redeem the coins. And those three people are going to be Alice, Bob, and some third party arbitrator, Judy, who will come into play in case there’s any dispute. So Alice creates a 2-of-3 MULTISIG transaction that sends some coins she owns and specifies that they can be spent if any two of Alice, Bob, and Judy sign.Escrows are very useful in the case of a transaction where a large amount money is involved and a certain number of obligations need to be fulfilled before a payment is released like in the case of a website being built where the buyer might want confirmation of the quality of work being done before making a full payment, and the seller doesn’t want to extend a massive amount of work without any assurance that he or she will receive payment.

     2.  Green addresses

                                          Say Alice wants to pay Bob, and Bob’s offline. Since he’s offline, Bob can’t go and look at the block chain to see if a transaction that Alice is sending is actually there. It’s also possible that Bob is online, but doesn’t have the time to go and look at the block chain and wait for the transactions to be confirmed. Remember that normally we want a transaction to be in the block chain and be confirmed by six blocks, which takes up to an hour, before we trust that it’s really in the block chain. But for some merchandise such as food, Bob can’t wait an hour before delivering. If Bob were a street vendor selling hot dogs, it’s unlikely that Alice would wait around for an hour to receive her food. Or maybe Bob for some other reason doesn’t have any connection to the internet at all, and is thus not going to be able to check the block chain.

Green addresses was a proposed use of special trusted ECDSA keypairs that to indicate the origin of funds to a recipient. Assuming the recipient trusts the operator of the keypair to not attempt a double spend, the recipient may treat the funds as confirmed the moment they arrive. This proposal is generally considered a bad idea and not advisable to implement.

As an example, assume website Z accepts incoming Bitcoin payments, but also trusts the green address published by Mt. Gox. Customer C wants to withdraw funds from Mt. Gox and send them to a payment address of website Z. A customer who does a withdrawal from Mt. Gox could click the use green address checkbox, which will result in the payment being sent to the "green address" derived from the special keypair as an intermediate step before forwarding the payment to site Z. Site Z can confirm that the payment passed through Mt. Gox's keypair and trust the payment as confirmed immediately, since it knows that the only party who could potentially perform an attack to reverse the payment is Mt. Gox.

       3. Efficient micro-payments

                                                    Say that Alice is a customer who wants to continually pay Bob small amounts of money for some service that Bob provides.  For example, Bob may be Alice’s wireless service provider, and requires her to pay a small fee for every minute that she talks on her phone. 

Creating a Bitcoin transaction for every minute that Alice speaks on the phone won’t work. That will create too many transactions, and the transaction fees add up. If the value of each one of these transactions is on the order of what the transaction fees are, Alice is going to be paying quite a high cost to do this. 

We start with a MULTISIG transaction that pays the maximum amount Alice would ever need to spend to an output requiring both Alice and Bob to sign to release the coins. Now, after the first minute that Alice has used the service, or the first time Alice needs to make a micro-payment, she signs a transaction spending those coins that were sent to the MULTISIG address, sending one unit of payment to Bob and returning the rest to Alice. After the next minute of using the service, Alice signs another transaction, this time paying two units to Bob and sending the rest to herself.

       4. Lock time

                              Alice and Bob will both sign a transaction which refunds all of Alice’s money back to her, but the refund is “locked” until some time in the future. So after Alice signs, but before she broadcasts, the first MULTISIG transaction that puts her funds into escrow, she’ll want to get this refund transaction from Bob and hold on to it. That guarantees that if she makes it to time ​ t ​ and Bob hasn’t signed any of the small transactions that Alice has sent, Alice can publish this transaction which refunds all of the money directly to her. 

 What does it mean that it’s locked until time ​ t ​ ? Recall when we looked at the metadata in Bitcoin transactions, that there was this lock_time parameter, which we had left unexplained. The way it works is that if you specify any value other than zero for the lock time, it tells miners not to publish the transaction until the specified lock time. The transaction will be invalid before either a specific block number, or a specific point in time, based on the timestamps that are put into blocks. So this is a way of preparing a transaction that can only be spent in the future if it isn’t already spent by then. It works quite nicely in the micro-payment protocol as a safety valve for Alice to know that if Bob never signs, eventually she’ll be able to get her money back. 

        5. smart contracts

                                       These are contracts for which we have some degree of technical enforcement in Bitcoin, whereas traditionally they are enforced through laws or courts of arbitration. It’s a really cool feature of Bitcoin that we can use scripts, miners, and transaction validation to realize the escrow protocol or the micro-payment protocol without needing a centralized authority. 

Research into smart contracts goes far beyond the applications that we saw in this section. There are many types of smart contracts which people would like to be able to enforce but which aren’t supported by the Bitcoin scripting language today. Or at least, nobody has come up with a creative way to implement them. As we saw, with a bit of creativity you can do quite a lot with the Bitcoin script as it currently stands.