Welcome to the third lecture
in our series on Bitcoin.
This lecture is going to be
all about the mechanics of
Bitcoin at a fairly low level.
So whereas in the first two lectures,
we've talked at a relatively high level,
in this lecture, we're going to be trying
to give it to you as real as possible.
So we'll look at real data structures,
real scripts, try to learn the details
in language of Bitcoin in a precise way
to set up everything that we want to talk
about for the remainder of the course.
So in some ways,
this will be the most challenging lecture,
because a lot of details
are going to be flying at you.
It's also one of the most real, where
you're really learning the specifics and
the quirks that make Bitcoin what it is.
So to recap where we left off last time,
the Bitcoin consensus mechanism
gives us an append-only ledger.
So a data structure that we can only
write to and once data is written,
it's there forever.
And there's a decentralized protocol for
establishing consensus about
the value of that ledger.
And the miners who perform that protocol
are validating transactions, so
making sure that transactions
are well-formed,
that there aren't double spends and that
this thing can function as a currency.
Although it's kind of funny,
because we assume that a currency
existed to motivate these miners.
So in this lecture, we'll be looking
at the details of how we actually
build that currency to make the miners
make this whole process happen.
[MUSIC]
All right, so we'll start by
looking at transactions in Bitcoin.
Transactions are really
the fundamental building
block which the whole currency
is going to be based on.
So remember we have this ledger.
The ledger is append-only, so as time goes
on we just add more and more units to it.
We're going to take a simplified model
here, where instead of having blocks,
we just have individual transactions
being added to the ledger one at a time.
So how can we build a currency this way?
So the first model you might think of,
which is actually a lot of people's
mental model for how Bitcoin works,
that we'll look at first,
is that you have an account-based system.
So you can add some transactions
that create new coins and
credit them to somebody.
And then later you can transfer them,
and you just have the transaction that
would say,
we're moving 17 coins from Alice to Bob.
That will be signed by Alice
to authorize the transaction,
and that's all the information
that would be contained.
Now backing this up, there would be some
state that says that after Alice received
25 coins in the first transaction, and
then transferred 17 coins to Bob in
the second transaction, Alice would have
an account that is left with 8 Bitcoins.
So, now after that transfer
from Alice to Bob,
we can add some more
transactions to the ledger.
We'll say that Bob pays
some Bitcoins to Charlie,
Charlie pays some coins to Alice,
and at this point, each participant,
Alice, Bob, and Charlie has an account
with a different value in it, and
those values are going to mutate
each time we add a new transaction.
Now the downside of this system, if we
add a new transaction at the bottom here,
is that we have to remember
what the account balance is for
each participant to figure out if
this transaction is valid or not.
Does Alice have the 15 coins that she's
trying to transfer to David here?
So sure enough,
looking at this just with your naked eye,
it's fairly hard to tell,
to do the mental arithmetic to figure
out if Alice has enough money
to transfer to David here.
And in fact, to figure this out, you'd
have to look backwards in time forever to
see every transaction affecting Alice and
whether or not her net balance at the time
that she tries to transfer 15 coins
to David is greater than 15 coins.
Okay, so to tell if this transaction
is valid or not, we have to figure out
whether or not Alice has the 15 coins
that she's trying to transfer to David.
And to figure that out,
we might have to look backwards
forever to the beginning of time at every
transaction that's ever involved Alice.
Every time Alice has sent or
received coins,
we need to find all of those
transactions and add them up,
to see if she really has the 15 coins
that she is trying to transfer to David.
And of course, we can make this
a little bit more efficient with some
data structures that track Alice's
balance after each transaction.
But that's going to require a lot of extra
housekeeping besides
the block chain itself.
And that's why Bitcoin isn't based on
an account-based model, like this.
Instead, Bitcoin uses a ledger that
just keeps track of transactions.
So, how does that work?
So, this is a transaction-based ledger,
which is very close to Bitcoin.
So now, transactions explicitly specify a
number of inputs and a number of outputs.
And transactions also each
have a unique identifier.
So we'll start with transaction 1,
which has no inputs, because this is
new currency being created, and
an output of 25 coins going to Alice.
And again, since this is a transaction
where new coins are being created,
there's no signature required here.
Now, let's say that Alice wants to
send some of those coins over to Bob.
Well, now she has to explicitly refer to
the previous transaction where these coins
were coming from.
So the input to this transaction will
be output index 0 from transaction 1,
which we can see from the very
previous transaction in the log,
was a transaction that
assigned 25 Bitcoins to Alice.
And now there are two
outputs of this transaction.
One of them is 17 coins to Bob, and
one of them is 8 coins to Alice.
And of course this whole
thing is signed by Alice so
that we know that Alice actually
wants to do this transaction.
And now you might ask, why does Alice
have to send money to herself here?
She's taken the 25 coins that were
assigned to her in transaction 1,
she only wanted to pay 17 to Bob, and
she has to have a new output where
8 coins are sent back to herself, possibly
to a different key, but to herself.
So this is what's called a change address,
and the design here is that you
always completely consume the output
of a previous transaction.
So there's no way to say I only need
17 coins from that previous output.
You have to say I'm using all 25
coins from the previous output, but,
since you want to keep some, you just
have a second output that sends some of
the coins back to yourself,
which is called a change address.
Now, let's say that we keep going
with this system and now we add a new
transaction and we ask ourselves again,
is this new transaction valid?
Now, it's much easier to look at
the block chain and figure out whether or
not this transaction is valid, because
we know exactly which input to look at.
So we just need to go to transaction 2,
output 1, and
verify that there's enough money there and
that it hasn't been sent already.
And of course we can look back and
say yes,
that second output of transaction
2 went to Alice with 8 coins.
Therefore it's enough to cover
the outputs of this transaction.
It's a finite backward scan to check for
the validity.
And we implement this with hash pointers.
So, again,
each transaction has a unique ID.
In reality,
they're not serial numbers like this.
It's the hash of the block.
And each transaction actually
gets its specific ID as well,
which is the hash of the transaction.
And now it's basically just following
one pointer to figure out whether or
not there's enough money to cover the
desired outputs in the new transaction.
Now conceptually, you can say maybe
this isn't that much different than just
maintaining a separate data structure,
which tracked account values for
each person.
But the nice thing is that now
this data structure is embedded
within the data in the block chain itself.
So some other things that we
could do quite easily here.
We can merge value.
So let's say there's two different
transactions that send some money to Bob.
17 coins in transaction 1,
and 2 coins in transaction 2.
Bob might say I'd like to have one
transaction I can spend later where I have
all 19 coins.
So this is pretty easy.
You just create a new transaction that
has two inputs now, and only one output,
so all of those coins go to Bob, and
you've combined the two previous
transactions into one that
Bob can then spend later.
Similarly, we can do joint
payments pretty easily.
So let's say that Carol and
Bob both want to pay David.
We can have a transaction with two
inputs that are actually owned by two
different people, and combine the value
and pay all 8 coins to David.
And the only extra thing here is that,
since the two
outputs that are being claimed here
are owned by two different people,
we're going to need two separate
signatures, one by Carol and one by Bob.
So conceptually, that's really all there
is to it, to a Bitcoin transaction.
And let's look at what it
looks like at the low level.
So again, one of the goals of this
lecture is going to be to show you
the real data structure,
the real deal of what Bitcoin looks like.
And, here it is.
Now this isn't exactly what
a Bitcoin transaction looks like.
This is a representation of
it that is pretty printed.
It looks kind of like JSON.
In reality, there's a compact binary
format that this gets compiled down to
that's not human readable, but
this is very close to the actual
low level transaction.
So there's three parts.
There's some metadata, there's a series
of inputs, and a series of outputs.
So we'll start with the metadata.
So there's some housekeeping information,
which is the size of the transaction,
the number of inputs and the number of
outputs, pretty straightforward stuff.
There's the hash of the entire
transaction, which as I said,
will serve as a unique ID for the
transaction to let us do hash pointers.
And then there's this funny lock_time
parameter, which I'll come back to later.
The transaction inputs is just an array
of inputs that all have the same form.
The inputs specify a previous
transaction specifically, so
they have the hash of the previous
transaction, or a hash pointer to it, and
the index of which output from that
transaction you're actually claiming.
And then there's the signature.
So remember that we have to sign to show
that we actually have the ability to claim
those previous transaction outputs.
And now the outputs have just two things,
they have a value, so
each output can have a different value,
the sum of the all the outputs has to
less than the sum of all the inputs.
And then there's this funny thing that
looks like what we want to
be the recipient address.
So each output is supposed to
go to a specific person or
to a specific public key.
And there is some stuff in there that
looks like the hash of a public key.
But there's also some other stuff.
It looks like a script.
And in fact, it is a script, and
we'll talk more about that very soon.
[MUSIC]