Hashlock

Bitcoin's Script language currently provides five opcodes that hash data contained within a transaction. The Script page describes a transaction that uses one of these hash functions to create a "transaction puzzle", a transaction output which can only be spent by someone who can satisfy this encumbrance:

OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL

The encumbrance above will take the data on the top of the stack (not shown), hash it with the sha256d function (creating a computed hash), and compare it to the string 6fe2...0000 above (the provided hash). If the computed hash equals the provided hash, then the encumbrance is satisfied and the output can be spent.

The Script page tells us that provided hash is the hash of the Genesis Block header, so the data necessary to satisfy this encumbrance is the header of the Genesis Block. Someone has already done that, so if we look up the transaction on the blockchain that spent this output, we would see that Genesis Block header in one of that transaction's scriptSigs.

By revealing that data used to create the hashlock (called a pre-image), the hashlock is rendered unusable for further security since everyone now has the key (the pre-image) and can do whatever they want to the funds encumbered by the hashlock. For this reason, outputs protected by hashlocks should also be protected by signatures so that both a correct pre-image and an appropriate signature are required to spend the funds.

However, hashlocks have the very useful property that multiple outputs can all be encumbered by the same hashlock, so that if the person who has the pre-image reveals it in order to spend their encumbered funds, everyone else who has an output encumbered by the same hashlock can get the pre-image they need from the first person's transaction on the blockchain.

This property allows payments to be routed through third parties without any risk that the third-parties will take the payment for themselves. For example,

• Dan creates a pre-image with 256 bits of entropy (randomness) and hashes it with the sha256d function, creating a hash.
• Dan gives the hash to Alice.
• Alice pays an output encumbered to Bob's public key plus the hash generated by Dan.
• Bob spends one of his previously-received outputs to Charlie, setting the amount to the same amount Alice paid him (minus fees) and setting the encumbrance to Charlie's public key plus the hash generated by Dan
• Charlie does the same as Bob, setting the encumbrance to Dan's public key plus the hash Dan generated

Now whenever Dan spends the output Charlie gave him, he's required to reveal the pre-image. Charlie can now use this to spend the output Bob gave him and Bob can use it to spend the output he received from Alice. In essence, Alice has paid Dan through the two intermediaries without giving Bob or Charlie the ability to steal the money for themselves.

This simple example is meant only to illustrate how hashlocks enable routability, so it uses direct Bitcoin transactions even though it makes no sense to pay through intermediaries with direct transactions. Also, the construction above is insecure because it relies on unconfirmed transactions and because it allows Bob and Charlie to hold Alice's funds hostage. For more practical examples, see the Uses section below.

• Hashed Timelock Contracts: This includes those used by Lightning Network and Atomic swaps.
• On-chain betting: Someone (called an oracle) generates multiple pre-images and their corresponding hashes; the players create outputs protected by a combination of signatures and hashlocks, and then provide all the necessary signatures to each other. Then the oracle reveals a single pre-image and deletes the rest; the players who won insert that preimage into the transaction along with the signatures they already have and collect their winnings. Note, this scheme does still require the oracle to be honest. Peter Todd believes that this scheme is inferior to one in which the oracle uses simple signatures.[1]

The hash functions in Script that are necessary to create hashlocks were part of the original Bitcoin 0.1 release.[2] In December 2010, after several problems were found with Bitcoin's opcodes, Gavin Andresen introduced the IsStandard() function[3] which prevented relay and mining by default of transactions using those hash functions and other rarely-used opcodes. After the opcodes received more auditing and had been enabled for years on testnet without issue, Bitcoin Core 0.10.0 (February 2015) removed most IsStandard() restrictions on P2SH transactions[4], re-allowing the use of hashlocks in transactions that are relayed and mined by default.