Guide | Output Locks
$5,412.22/BTCBuy

Output Locks

What is an output lock?

An output lock is a set of requirements placed on an output. These requirements must be met to be able to use the output in a transaction.

For example, the most common output lock reads something like this:

It’s these locks that prevent us from spending each other’s outputs in a transaction, as every output we receive is encumbered by a lock.

Where do output locks come from?

As we know, a transaction is the process of taking existing outputs and creating new ones from them:

A transaction.

A transaction.

And it’s during the creation of these outputs that we give each one a “lock”.

Creating new outputs and giving each one a lock.

Creating new outputs and giving each one a lock.

So when we want to send bitcoins to a friend, we create the new output, and add a lock that says “only the owner of 1friend1234567890 can use this output”.

All of this is stored in the transaction data.

All of this is stored in the transaction data.

As a result, this new output will effectively “belong” to our friend, because they are the only person who has the private key for this address, so nobody else will be able to spend it.

How do you create an output lock?

Output locks are written in a basic programming language, called SCRIPT.

It’s a bit tricky to explain the workings of an entire programming language in one diagram, but here we go anyway:

This lock we program is called a locking script.

This lock we program is called a locking script.

Now, the most interesting part of this locking script is CHECKPRIVATEKEY, which is a function that we use to help set the requirements for the lock.

So for this particular output, we’ve set a lock that wants to compare the address 1EUXSxuUVy2PC5enGXR1a3yxbEjNWMHuem with a private key.

If we can provide this lock with a matching private key, we can unlock it and use it in a transaction.

How do you unlock an output lock?

When you construct the transaction data, you include an “unlocking script” after each output you intend to use:

So for example, to unlock a typical locking script (e.g. [address][CHECKPRIVATEKEY]), we need to prove that we own the address [address]. To do this, we use our private key to create a digital signature.

You put your digital signature as the unlocking script.

You put your digital signature as the “unlocking script”.

So when a node receives this transaction data, they will run the “locking”+“unlocking” scripts together to see if your digital signature matches the address that the output has been locked to.

If everything is cool, the node accepts the transaction and passes it on to other nodes, who will each in turn run the “locking”+“unlocking” script before accepting the transaction.

And that’s how you unlock an output lock.

What the bejeebus? We’re giving away our private key!

Astute observation, sir.

Confession: We don’t actually put our private key directly in to the transaction data.

You see, to save us from giving our private key away within the transaction data, we create something called a “digital signature”:

We use our private key to make a digital signature.

We use our private key to make a digital signature.

Obviously I lied about that function we used too. But no fear, there is actually one that compares an [address] with a [digitalsignature], and it’s called CHECKSIG.

Still does the trick.

Still does the trick.

And thanks to the magic of digital signatures and the CHECKSIG function, we can still lock outputs to addresses, and also be able to unlock them without having to give away the private key.

Quite awesome.

Greg Walker, 08 June 2015

Back to Top