Output Locks
Locking mechanisms for batches of bitcoins.
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:

And it’s during the creation of these outputs that we give 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”.

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:

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.

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”:

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
.

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.