Something cool you can do with Bitcoin Script is write arbitrary data into the Bitcoin blockchain.
This is the idea behind proof of burn.
There’s an opcode in script called OP_RETURN that throws an error if it is reached.
If you specify a script that has OP_RETURN before the output script, then the output can’t be spent, since execution terminates before then.
If this transaction is published on the blockchain, then you’ve successfully proven that you have destroyed some bitcoin.
No one can ever spend that bitcoin again, since you’ve burned it.
Below OP_RETURN, there’s space to put whatever you want.
One thing you can do with this concept of burning bitcoin is that you could bootstrap an altcoin, requiring that you must destroy some Bitcoin, and show a proof of this, in order to get some altcoin.
Some altcoins such as CalCoin do this.
Aside from using OP_RETURN for the sake of deriving an altcoin’s value, you can also write arbitrary data into the blockchain.
Under OP_RETURN, there’s space to write whatever you want, so people have been creative with this.
You could potentially prove the existence of something at a particular point in time.
For example, if you coined a new word, and wanted to prove in the future that you had coined this word in the past, you could simply burn this data into the blockchain.
As we mentioned before, the Bitcoin blockchain is immutable, meaning that it cannot be changed realistically.
Transactions are also timestamped, so people can see that you had actually coined this word in the past.
Aside from words, you could also prove the existence of a document, a piece of music, other creative works, or anything else, so long as you have bitcoin to burn.
Intro: Advanced Bitcoin Script and P2SH In this section, we’ll look at how to create arbitrary scripts in a scheme called P2SH, or Pay to Script Hash.
For a better understanding, we’ll compare pay to script hash to the scheme from the previous section: pay to pub key hash.
And , to make for a better mental model, we’ll be explaining everything in terms of a vendor-customer scenario, where the customer creates a transaction to pay the vendor.
In other words, the customer is the sender, and the vendor is the recipient.