The Bitcoin wiki describes a transaction’s script as something that describes “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” is described as requiring of the future spender:
- a public key that, when hashed, yields destination address D embedded in the script, and
- a signature to show evidence of the private key corresponding to the public key just provided.
What useful alternative scripts could be made? What practical situations would they serve, and what client features would be required to support them?
If a full implementation of the scripting language were in place, then pretty much all of the following could be implemented. However, there are serious security concerns with some of these and they warrant further analysis before finding their way into the clients.
The referenced Scripts link in the original question contains several script examples covering the following use cases which are worth listing before getting to the more exotic cases:
- Standard generation/transaction to Bitcoin address – this is the typical situation everyone uses when sending/receiving bitcoins
- Standard generation/transaction to IP address – a method of automatically getting the recipient to generate a Bitcoin address so long as their IP is known (very dangerous due to man-in-the-middle attacks)
- Transaction with a message – Add arbitrary text to a transactions (typically limited to around 10,000 bytes) which allows for ASCII art and other graffiti, perhaps even a steganographic exploit
- Hidden recipient address – allows the address of the recipient to be encrypted so that only a shared secret between them allows the bitcoins to be spent
The further linked Contracts page on the wiki provides these additional use cases which are somewhat more complex:
- Providing a refundable deposit – handy for proving that you’re willing to spend money to ensure that you’re reputable, with the option to get it back after a given time
- Escrow and dispute mediation – permits several parties that don’t trust each other to trade using their common trust of a given set of trusted third parties (this is the classic M of N signatures to release the funds contract)
- Assurance contracts – essentially to allow pledges to be given for the greater good by competing parties (example is to pay for a lighthouse)
- Using external state – Scripts can consult addresses that may be attached to “oracle scripts” which can perform transaction signing based on complex internal logic (example is to guarantee payment of an inheritance upon death or coming of age whichever is the sooner)
- Trading across chains – Allows other Bitcoin based currencies to trade against each other (thus potentially solving this problem for countries wishing to use Bitcoin)
Clearly there are many opportunities for exotic transaction types:
- Proof of knowledge – to prove that knowledge was acquired at a certain time a transaction could be created that references an oracle script that could provide verification. The oracle may not exist at the time of presentation, but it would be trivial to run the script and verify the outcome.
- Payment on successful prediction – another external state use case to allow an external oracle to sign a transaction based on pre-arranged transaction outcomes (examples include gambling, spread betting etc)
All in all, it shows that Bitcoin is a very effective financial trading instrument.