The following content is provided under a Creative
Commons license.
Your support will help MIT OpenCourseWare
continue to offer high-quality educational resources for free.
To make a donation or to view additional materials
from hundreds of MIT courses, visit MIT OpenCourseWare
at ocw.mit.edu.
NEHA NARULA: OK, let's get started.
I hope everybody had a great long weekend.
So I'm teaching today, and today we're
going to be talking about transactions.
So just to recap where we've been so far,
Tadge just sort of explained signatures in Bitcoin,
in particular RSA and ECDSA, and told us a little bit
about Merkle trees.
And so these are some of the underlying primitives
that we need to know about in order
to understand how most of the blockchains today
are constructed.
So we've spent a bit of time talking about the underlying
primitives, now let's start to put them together a little bit
to understand what goes into a blockchain.
So if you recall, this is a slide
that Tadge has shown before.
And I'm really sorry about this quadrant, but I don't know,
I don't think I can control this individually.
So we'll definitely post the slides of course,
but let me know if something is really confusing.
Just raise your hand.
So this is something that you guys have seen before,
and it's like a very sort of rough approximation
of a hash chain.
So what we have here is we have--
this doesn't actually show the previous,
but what we have here is we have some message,
we have a nonce, such that when you hash these three
things together, you get this hash value,
which has a certain number of leading zeros at the beginning.
In this case, it's two leading zeros.
And when we construct the next block,
we implicitly point to this previous block
by including that hash inside of this when we produce this hash.
So note that there isn't actually
a physical pointer or a memory address
pointer type thing connecting these two things together.
And note that this block does not actually
contain the hash of itself.
But we are sort of implicitly pointing to this
by including the hash of this block in the following block.
And so on over here-- again, this is a different message,
a different nonce, and it includes
the hash of this block instead of the one before.
And by including the hash of this block,
it's also implicitly including the hash of this block,
because that's right here.
And so what we're going to see is that if you change anything
about the previous blocks in the blockchain-- for example,
if you change this message--
then you're going to need to change the nonce in order
to get the hash to compute right.
That's going to be a different hash.
And that change is going to trickle down
through the entire blockchain.
And so that's what makes these things what
we call tamper-proof, the fact that there are these hashes,
these hashes are collision-resistant.
And so it's very difficult. You can't change what's in the past
without having it reflected in the future.
So now let's go into a little bit more
detail about exactly what this message thing is.
We've talked about the previous hash pointers,
we've talked about the nonce, we've
talked about proof of work.
But what actually goes inside of a block?
Well, we have this general-- we've
kind of been alluding to it, but what
goes inside a block are transactions.
We're trying to build a payment system here.
So what do we need to have in a transaction?
What should a transaction look like?
Yes.
AUDIENCE: Inputs and outputs.
NEHA NARULA: OK, inputs and outputs.
Maybe even like a higher level here, semantically,
what do we want in a transaction?
Yep.
AUDIENCE: A sender, a receiver, an amount, like a message.
NEHA NARULA: OK, a sender, a receiver, an amount.
Anybody else?
AUDIENCE: Transaction ID.
NEHA NARULA: OK, an ID, some way of referencing it.
Anybody else.
Yep.
AUDIENCE: A proof that it's a legit transaction.
NEHA NARULA: A proof that it's a legit transaction, right,
exactly.
So what we need is those things that you guys just said.
We need to know the amount, how much of this coin
we're transferring, we need to know where it's coming from,
and in particular we need an authorization of some sort
that that user actually authorized the spend,
and we need who we're paying.
And so unfortunately this is in the dark part,
but this is sort of a little rough sketch of a transaction.
And we have Alice who's spending $5.00 to Bob,
and we have this authorization here.
And this authorization, given we just learned about signatures,
signatures are a great way to do authorization
because it's something that only Alice can produce.
So I don't know if you can see this,
but there are question marks here.
So what should Alice sign to show that she
authorized this transaction?
What do you think would be a good thing--
what is a good message for her to sign
for her to indicate her authority, her desire
to produce this transaction and spend her funds?
AUDIENCE: Private key.
NEHA NARULA: Her private key?
AUDIENCE: Yeah.
NEHA NARULA: She should sign her private key?
OK.
AUDIENCE: [INAUDIBLE] the whole transaction.
NEHA NARULA: The whole transaction, OK.
So let's talk about signing the private key.
Let's say that she did sign her private key.
The problem with a signature is that, in order
to tell if the signature is valid,
you need the thing that you signed.
So she would have to include her private key, which would then
share her private key with everyone, which isn't really
a good way for her to use her public and private key.
She could certainly sign the transaction.
And the nice thing about signing the transaction--
this is all blue, indicating that she's signing it--
is that she's signing all three of these things as well.
She's saying, I want to pay Bob, I want to pay Bob $5.
Now what's the problem with signing the transaction?
Yes.
AUDIENCE: Couldn't you just keep using it if you were Bob?
NEHA NARULA: So that is an excellent point-- you could
keep using it if you were Bob.
And we'll get into that a little bit later.
But another problem here is, the way
that I've shown it right now, she's signing the signature.
The signature is kind of part of the transaction.
And so you want to make sure that you're not--
when you sign a transaction, you're
signing everything but the signature, right,
because you can't produce the signature.
You can't sign the signature without knowing
what the signature is.
It would be like a whole new type of proof of work
on the transaction.
So I don't know if you can see this,
but this says transaction minus signature.
And in fact, we can even make that a little bit easier
by turning that into a hash of the transaction,
not including the signature.
Because that sort of brings the message
down to a smaller thing.
And from what we know about hash functions you can't really,
given a message and a hash of that message,
it's difficult to produce another message that
would hash to the same thing.
So this hash serves as kind of an identifier
for the transaction as a whole.
In fact, Bitcoin uses the hash of this as the transaction ID.
So this is how we refer to transactions.
And it's a nice small thing to sign,
which indicates Alice's intent to spend her funds.
So one thing that I kind of want to go into a little bit
is that there's a couple different ways for thinking
about transactions, and what transactions actually
look like, and how they're stored,
and how we sort of specify coins.
And the most natural model, to me, anyway, not to everybody,
perhaps, is what I call the account-based model.
So it's kind of like what we were doing before,
when we saw the banks, and we were
talking about banks keeping track
of how much funds people have.
And this is sort of how you and I might think of our own bank
accounts.
I think in my bank account as having a certain amount
of funds in it.
And so in the account-based model,
users have certain amounts or balances associated
with their usernames.
And when a transaction comes in, like Alice wants to give $5.00
to Bob, then what might happen is that the nodes
in the network which are all maintaining, in a unified way,
this balance sheet, will end up saying, OK,
Alice had 10 and Bob had zero.
Alice wants to give $5.00 to Bob.
Let's subtract $5.00 from Alice's account and give it
to Bob.
And so what the nodes would do here
to see if this transaction was valid would be
they would check the signature to make sure
that Alice actually authorized this transaction,
and they would also make sure that Alice
had the funds to spend.
And in the account-based model, the way
that you check to see if Alice has the funds
to spend as you literally look at her balance,
and you look at the amount she wants to spend,
and you make sure that if she spends that amount,
the balance won't go below zero.
So this is actually the model that Ethereum uses.
It's not the model that Bitcoin uses.
So just sort of to summarize, you
store a list of accounts and balances,
a transaction is valid if there is a balance in the account,
and then when a transaction is processed,
you debit the sender and credit the receiver-- so
very straightforward.
So like I said, this is a way Ethereum works,
and it's a little bit more natural,
I think, to think about.
But this is not the way Bitcoin works, actually.
Bitcoin has a very different model
of coins and of transactions.
And I think-- when I was learning about how Bitcoin
worked and how Ethereum worked, I
found Bitcoin's model a little bit unnatural
until I went through this exercise of thinking
about something called replay attacks.
And this is what [? Issan ?] mentioned earlier, which
is when you have this transaction,
and you send it to the network, and the network
processes the transaction and debits Alice and credits
Bob, what is to prevent a malicious agent from noticing
that transaction and rebroadcasting it again
to the network, so basically repeatedly debiting
Alice until she doesn't have any funds left.
So can you guys think of a way to maybe get around this?
What would you do?
How would you prevent this replay attack?
Yeah.
AUDIENCE: She can add a specific ID to the time, for instance,
[INAUDIBLE]
NEHA NARULA: So one thing is adding a time, sure.
Time is a little bit tricky because of the nature
of the system.
But a time is a pretty good idea.
A unique number of some kind certainly
would help, because that way if you saw a transaction
with the same number, then you'd know,
OK, this transaction has been seen before.
This is a repeat.
This is a rebroadcast.
This is not something I should process.
So Ethereum actually does something like this.
There is this number included in every transaction.
But the tricky part about the way that Ethereum does this--
and we're going to learn more about Ethereum later
on in the course, we're going to have a guest lecturer come
in and teach us about that--
is that it requires you to keep track of all of the numbers
you've seen.
And you have to do this per user.
And so all the nodes in the network
have to keep track of all of the nonces
that they've seen per user.
And so if a user uses Ethereum once and then goes away,
all of the nodes have to keep that state forever,
essentially, just in case someone
comes back and rebroadcasts another transaction.
So Bitcoin, like I said, and I keep saying, does something.
And there's nothing wrong with this model.
We'll sort of compare and contrast.
Like I said, it's what Ethereum uses.
But I think that this is part of the motivation for why
Bitcoin was designed the way that it was.
And so Bitcoin uses this idea called unspent transaction
outputs.
So you'll notice, over here, we don't have
any notion of a coin, per se.
There are just amounts, and amounts
are debited and credited.
And if Alice spends to Bob, and Alice spends to Carol,
and they come in different orders,
either one could happen first.
There's no notion of, like, Carol gets these coins
and Bob gets these coins.
But Bitcoin is a little bit different.
All coins are not the same.
And when you're spending, you don't just
include an amount you refer back to the specific coin
that you are spending.
So you actually have to refer to a coin in order to spend it.
And this is the really weird part--
coins are created, destroyed, consumed,
and then new coins are created every transaction.
So whenever you spend your bitcoin,
you have to spend it in its entirety.
That bitcoin is then destroyed, and new coins are created.
And there's a rule, in the entire system, that a coin can
only be spent once.
So we'll go into exactly what that
looks like in a transaction, but I
want to know if there are any questions about that
first, about that idea.
Yes.
AUDIENCE: Aren't coins fungible?
So what if you spend maybe a little bit of a coin
on some candy or something?
NEHA NARULA: That's a great question.
So the question is, aren't coins fungible?
So first of all, coins aren't fungible, actually.
They are very specific.
You can see a coin.
But the question about what happens
if you only want to spend part of a coin is a great question.
And we'll see how you do that in the way
that the transaction is constructed.
But the short answer is, if you want to spend part of a coin,
you have to spend the whole coin,
spend the part that you want to someone else,
and then spend the rest of it back to yourself,
creating a new coin in the process.
Yes.
AUDIENCE: Coins are consumed, and for the new ones,
who will own the new ones?
NEHA NARULA: Whoever you say should own the new ones when--
a transaction consumes coins and creates new ones as payment.
And as the creator of that transaction, as the spender,
I will decide who should get the new coins.
And I'll show you the details of this in a moment.
AUDIENCE: You're saying coins, but do
you actually mean the full balance in the account, right?
NEHA NARULA: No, not exactly full balance in the account.
So let's go a little bit further to look
at what's happening here.
Because Bitcoin doesn't actually keep track of balances.
So let's take a look at what a transaction actually
looks like.
So a transaction has many different parts,
but we're going to focus on two parts, which
is the inputs and outputs.
And here I'm showing a transaction
with one input and one output.
Now, an input actually refers back
to another transaction's output.
So let's assume-- and we'll get into how this is done later--
but let's assume that there are coins in the system.
Let's just assume that some coins have been created out
of nowhere.
Let's say, in particular, that maybe 12.5 coins have
been created out of nowhere.
And so there's a transaction that
outputs 12.5 coins to Alice.
And Alice wants to spend those coins.
And so Alice would create a new transaction
that points back to the transaction where
she received those coins.
And the way that she points back to that
is using the transaction ID of the previous transaction, which
you remember is just the hash, the index,
meaning which output of the previous transaction she's
intending to spend, and something
called a scriptSig, which is her authorization
to spend that output.
So this is how Alice refers back to the output
she wants to spend.
And when I say coin, I'm referring to outputs.
So outputs can be for different amounts.
You could create an output--
you could spend 12.5 coins and create many different outputs
of many different amounts, and send them to different people.
if you wanted to.
So this is a format of a transaction.
There is an input which points back
to a previous transaction's output
that you're intending to spend.
And then the way that you spend it--
you're consuming that output, essentially,
by pointing back to it with this input--
the way that you spend it by producing a new output.
And again, this transaction isn't just
one input and one output, it could have many.
And the output that you produce has something
called a scriptPubKey.
What the scriptPubKey is, the scriptPubKey
is a way of specifying the conditions under which
this output can be redeemed.
So in its simplest sense, you might have the scriptSig merely
be a signature, just Alice's signature, saying,
I have the right to spend this.
And if Alice is spending to Bob, then maybe the scriptPubKey
would actually just be Bob's public key.
And the implied meaning there would
be, anyone who could produce the signature
of the corresponding private key with that public key
could then spend this output.
One thing is that these two things together--
the previous transaction ID and the index--
serves to uniquely identify an output.
So these two things uniquely identify some money to spend.
And the value that's specified in the output
is actually specified in something called Satoshis,
and there are 10 to the eighth Satoshis in one bitcoin.
So the value doesn't have any decimal places in it.
It is always an integer.
And output is what I'm referring to when I say the word, coin.
So, questions on this sort of general setup.
Yes.
AUDIENCE: Can you talk about index [INAUDIBLE]
NEHA NARULA: Sure.
OK, the index is--
remember how I said there could be multiple outputs?
The index simply refers to which output
in the previous transaction you're talking about.
Was there a question back there?
Yeah.
AUDIENCE: Yeah, I'm a little bit confused about the--
So you have one input that can generate several outputs?
NEHA NARULA: Yes.
AUDIENCE: Can you provide an example?
NEHA NARULA: Sure, yes.
We'll get to that in a moment, actually.
But maybe I could just draw one on the board.
So you could certainly have a transaction
that has multiple outputs.
And so this input here would refer back
to some previous transaction's outputs.
And let's say that this was, for example, 20 bitcoin.
Then this needs to consume 20 bitcoin.
And it can spread that 20 bitcoin out in any way
that it wants.
And there are some details here that we're
going to get to in a moment.
But basically, you have that 20 here.
You could send five here, 10 here, five here.
And each of these outputs would have its own scriptPubKey,
its own rules for how to redeem it.
And each output has its own amount.
Yep.
TADGE DRYJA: It's also possible with multiple inputs
[INAUDIBLE]
NEHA NARULA: Yes.
Yes.
AUDIENCE: So where does the name, chain, come from?
Is it more like a tree, or is it--
NEHA NARULA: That's a good question.
So if you go back to the slide where I sort of was showing--
this is where the name, chain, comes from, here.
[CHUCKLING]
So what we're talking about right now
is what goes inside each block.
And what goes inside each block are transactions.
So for the moment, you can pretend like each block only
has one transaction in it, but a block
can contain a set of transactions.
But the chain part comes from how we actually
chain these blocks of transactions together.
So let's talk about scriptSigs and scriptPubKeys a little bit
more.
So scriptPubKeys, like I said, are in the outputs.
And you can think of them as predicates.
So scriptPubKeys specify a predicate
on how someone can redeem this output.
OK, so remember a transaction can have multiple inputs,
multiple outputs.
Each output has its own scriptPubKey.
scriptSigs, which are in the inputs,
helps satisfy the predicate that's
specified in the scriptPubKey.
So we would have a scriptPubKey here, And.
We would have a scriptSig here.
And this scriptSig, if this is a valid transaction,
would explain how to satisfy the scriptPubKey.
So the scriptPubKey would set up a predicate on the output.
The most common predicate is, produce
a signature and a public key that satisfies this hash.
And the scriptSig would provide the information
necessary to satisfy that predicate.
So what does it mean to have money in this system?
What does it mean to be able to spend money?
What does it mean for Alice to be
able to transfer money to Bob?
It means Alice knows some information that
allows her to produce a satisfying scriptSig
for some outputs out there.
That's what having money means.
It's not an account balance.
So questions on that?
Because it's a little non-intuitive.
But the important thing to note here
is the nodes in the Bitcoin network
are not keeping track of how much money you have.
It's your job to keep track of how much money you have,
or a wallet's job.
And we'll talk more about wallets later.
And the way that you do that is by knowing
how many outputs there are out there that you can actually
redeem--
that you have the knowledge to redeem.
Like I said, a transaction can have multiple inputs
and multiple outputs.
And each input comes with its own scriptSig,
and each output comes with its own scriptPubKey.
So it's not that there's one scriptSig and one scriptPubKey
for the entire transaction.
The transaction can actually spend
multiple different outputs and produce
multiple different new outputs.
And these outputs could have nothing to do with each other.
Here, this input might point to a previous output
that Alice knows how to spend.
And this input might point to a previous output
the Carol knows how to spend.
And you can actually combine both of those
into the same transaction, assuming
you can produce a transaction with the right scriptSigs.
Now, Alice and Carol might have to talk to each other
in order to produce this transaction,
because it's going to need both signatures,
but they could do it.
AUDIENCE: What prevents people from sort
of shuffling around and changing the outputs
and inputs [INAUDIBLE]?
NEHA NARULA: Ah, great question.
So what prevents people from shuffling
around inputs and the outputs?
Well, part of it is because this is
serialized into a transaction.
And that transaction is hashed, and then these signatures
are on that transaction hash.
Remember, we saw that from a few slides before.
So if you were to flip around the order
or if you were to trying to change any bits in here
and change the pubkey, you would end up
changing the hash of the transaction
and this signature would no longer be valid.
And something also that's important to note--
only valid transactions get accepted to the blockchain.
So all of the nodes are checking to make sure
that these scriptPubKeys and these scriptSigs work out.
And I'll show you the rules that they're
checking in just a moment.
And so if anything doesn't match,
if this signature is not a valid scriptSig for whatever output
it's pointing to, this is an invalid transaction,
no one will accept it.
In fact, most nodes won't even pass it around,
and it will not get into the blockchain.
Or if it does get into the blockchain,
all of the nodes who are following the rules
of the network will ignore it.
Because if a transaction is invalid,
it means the entire block is invalid,
and it means any chain building off that block is also invalid.
So nodes that are following the rules of the network, which
are, these should be valid, will not listen to that,
and will completely ignore that entire chain.
So here's another visual of what it looks like to have--
and this is not with the blockchain looks like.
I want to be clear.
The blockchain just a set of blocks
pointing to previous blocks.
What we have here is more sort of
like the logical representation of what
a transaction looks like.
So you have a transaction right here,
and you have two inputs in this transaction.
And the first one is pointing to the second output
of this previous transaction that happened over here.
So this transaction has a hash.
And maybe this is the hash of the entire transaction.
And so in order to spend that output over there,
you specify the hash, you specify the index--
so 012, you specify this index right here--
and you provide a scriptSig that will
validate according to whatever the scriptPubKey is
for that output.
So note here, this transaction doesn't care
what those outputs are at all.
It's not using those.
It's not looking at those.
Someone else might spend those, someone else
might not spend those.
It's just spending this one right here.
And in the act of spending this one right here,
it doesn't make those other ones invalid in the simplest form.
Those could still be spent by someone else.
So outputs are consumed separately.
So here, it's pointing to a different transaction,
a transaction with this hash.
And so it specifies the transaction ID,
and then it specifies which output in that transaction
it's spending.
In this case, it's the third one, so it has index 2.
And it provides a satisfying scriptSig
for this output, which probably is
totally different than the satisfying
scriptSig for that output.
So this is what this transaction has to specify in order
to spend those outputs.
And it can produce whatever new outputs it wants
to produce under certain rules.
AUDIENCE: So in that example, that whole box actually
points to something else?
That's not these two boxes on the left, right?
NEHA NARULA: This box?
What do you mean when you say, points to?
AUDIENCE: [? Their ?] blockchain sequence.
NEHA NARULA: Yeah.
This is something that will be inside
of the blockchain-- inside of a block in the blockchain.
So this doesn't actually point to anything.
It contains hashes.
Literally, it just contains these bytes,
these hashes of the transactions that it's spending.
And those are kind of like a pointer in a sense.
But when it comes to the entire blockchain,
this is one part of one block.
AUDIENCE: [INAUDIBLE]
NEHA NARULA: Yeah, I know.
Can you guys see this at all?
Can you still see that or no?
OK, good.
OK, great.
You had your hand up.
AUDIENCE: Yeah, so in one of the earlier slides,
you showed [INAUDIBLE] Is that signature the same
as scriptSig, or--
NEHA NARULA: No, that was sort of more
like an idealized transaction.
So this is what a transaction actually looks like,
[CHUCKLING]
AUDIENCE: But the scriptSig is still
inside the transaction itself.
NEHA NARULA: The scriptSig is inside the transaction.
But when you sign the transaction,
you don't sign the scriptSigs because the scriptSigs include
the signature of the transaction.
And it's important to note, the scriptSig
includes the signature of the transaction as a whole,
not just this part of it.
TADGE DRYJA: This actually [INAUDIBLE] We're not talking
about it now, but that was sort of--
there's bugs involved at that point.
NEHA NARULA: Yeah, we're not going
to talk about [INAUDIBLE].
OK, yes.
AUDIENCE: Yeah, what prevents two different transactions
pointing back at the same [INAUDIBLE]??
NEHA NARULA: Great question.
So OK, I said that there's this rule that outputs are supposed
to only be consumed once.
But I can definitely produce another transaction which
points back to that output.
I could send it to the network.
And what would happen is the nodes in the network,
assuming they're following consensus rules,
would note that this had already been spent.
So if this is already-- if they've already
seen a valid transaction that consumes an output,
they will not accept another transaction that
tries to spend the same output.
That's what's known as a double-spend.
And so all the nodes in the network
together are maintaining this rule.
AUDIENCE: Isn't it going to be kind of hard to traverse
backwards and figure out [INAUDIBLE]
pointing [INAUDIBLE]?
NEHA NARULA: Great question.
Yes, this seems kind of annoying, right?
You see this transaction, and OK, there's
some random bytes in here, and a signature,
and how am I supposed to figure out what this goes to?
How am I supposed to figure out whether this
is a valid transaction, whether it's been spent or not?
And the answer is that every single node
is maintaining a lot of data structures
in order to make this faster.
And in fact they're maintaining a data structure
called the UTXO set.
And I'll tell you a little bit about the UTXO set in a minute.
And I'll tell you how it's created in a moment.
Yes.
AUDIENCE: [INAUDIBLE] transaction fees
and how these transactions pass in to the blockchain itself?
NEHA NARULA: Sure.
So I'm not going to go into how a block--
what a block is composed of.
I'm not going to go into what a block is composed of,
but we will tomorrow.
Yes.
AUDIENCE: Just to confirm, with the [INAUDIBLE] scriptSig,
it's not usually [? taking ?] this,
it's [INAUDIBLE] the transaction.
NEHA NARULA: I'm sorry, could you say--
AUDIENCE: ScriptSig, [INAUDIBLE] or is it unique for each index?
NEHA NARULA: Yes, there is a different scriptSig
for each input.
There's a different scriptSig for each input,
but that scriptSig signs most of the transaction.
So the scriptSig, there's a different one,
because different outputs could have different satisfying
conditions.
But the scriptSig has to sign a message,
or it has to produce something.
Actually, we're going to go into a few specific scriptSigs,
and I think it'll be a lot clearer exactly what this is.
Because it's not clear right now what goes in the scriptSig
or in the scriptPubKey.
So this is sort of like a logical representation of what
a transaction looks like.
It refers to the previous transaction
that it's spending from.
And the important things to note here
are you don't have to spend all of the outputs
in a transaction, you can just spend one.
But you must consume that output entirely
when you produce your new outputs.
And so this is what's actually--
this is the JSON representation of a transaction in Bitcoin.
And so this is probably pretty hard to read,
and I don't think it's worth it to try to look
at everything in great detail.
But when we have the slides up, you can take a look at this.
And this is literally what goes inside a transaction.
And there are few fields that I'm not talking about here.
One is the version, and another is the lock time.
And I think when we talk--
these scripts, these scriptPubKey and scriptSig
can actually get quite interesting and quite complex.
That's what makes Bitcoin so cool.
And I think when we get into that discussion about all
the different things that can go into that,
then we'll talk a little bit more about what lock time is.
But the short answer is, a lock time tells you
at what point in time this transaction is valid.
So until that lock time happens, the transaction
is not valid and can't be included in the blockchain.
So this transaction has a lock time of zero,
meaning it's valid immediately and can
be included in the blockchain.
So here, this has one input.
The input has the transaction ID and the index.
So that's zero, so it's spending the first output of whatever
that transaction is.
And it has some scriptSig, which is empty.
And then this is the output that it's producing.
It's spending 49.99 bitcoins from that previous output.
And it's spending it to a new output.
And these are the rules for redeeming this new output.
Let's talk about consensus rules.
So I keep using the word, valid--
this transaction is valid, this transaction is invalid.
And so there are these implicit rules
to Bitcoin, which are defined by the software, which
state what makes a valid transaction or a valid block.
For transactions specifically, the sum of the inputs
has to be less than or equal to the sum of the outputs.
So you can't create money out of nowhere.
You can't spend more than you're putting into a transaction.
And why less than or equal to?
Fees, exactly.
So the difference in the outputs and the inputs is implicit.
And it's a fee that essentially just goes
to the miner, the person who purchases the block.
There is one exception to this rule.
It's a transaction called the coinbase transaction--
no relation to the company.
It's not named after the company.
I think the company is named after it.
But it's the first transaction in a block.
And it's the transaction that gives out the block reward.
So the first transaction in a block is special.
It doesn't have any inputs.
Or it does have inputs, but they're meaningless.
And it produces the block reward.
So right now, the block reward is 12.5 bitcoins.
So every time a block is produced,
every time someone solves that proof-of-work puzzle
and produces a block, they include a transaction
at the very beginning that usually gives themselves
12.5 bitcoin plus whatever fees are
implicit as the sum of all of the transactions in the block.
So this invariant must be maintained,
except for the coinbase transaction, of which there
is one in every block.
And then this invariant must also
be maintained, which-- oh, yes, sorry.
AUDIENCE: Who determines the fees?
NEHA NARULA: The people creating the transaction
determine the fees.
So when I create a transaction, I'm
specifying which outputs I'm spending, and putting them
in my inputs, and I'm producing the outputs.
So I just have to maintain that invariant.
So let's say that I'm spending an input worth five bitcoin.
I could produce an output worth five bitcoin,
meaning that the fee is zero.
It's very unlikely that my transaction
would get accepted into the blockchain with a fee of zero.
It's possible, sure.
But if I'm not mining myself, why would
a miner take my transaction when they
could take a transaction that has a higher fee associated
with it?
And the fee is implicit.
It's the difference between the sum of the inputs
and the sum of the outputs.
AUDIENCE: So higher the fees, it's more likely
that you will be processed--
NEHA NARULA: Yes.
Any other questions at this point?
AUDIENCE: Are these taken out of the inputs
or out of the outputs?
NEHA NARULA: The fee is implicit.
So, in the inputs, you're consuming--
so let's use this example right here.
So here, we're consuming this output,
which has 20 bitcoin in it.
So implicitly, this thing has 20 bitcoin to spend.
Now, before, I had it set up as 5-10-5.
And so 20 needs to be greater than
or equal to 5 plus 10 plus 5.
And it is, great, 20 is greater than or equal to 20.
What I could do is I could change this number to a four.
And so what this means is--
notice that this adds up to 19 now.
Where did that one bitcoin go?
That one bitcoin implicitly goes to whoever
produces the block in which that contains this transaction.
AUDIENCE: So is that greater than--
[INTERPOSING VOICES]
AUDIENCE: No, but [INAUDIBLE]
NEHA NARULA: No.
AUDIENCE: On the slide.
NEHA NARULA: Yeah, you're right.
Sorry, that should be greater than or equal to.
Sorry about that.
So another invariant that needs to be maintained
is that this output has not already
been referenced in another transaction,
in another valid transaction.
And then, as I alluded to, a final invariant
is around the lock time.
So let's go into an example of how this actually works,
this scriptSig and scriptPubKey thing.
So I haven't really gone into detail yet about what this is.
I sort of implied that this specified a key and this
specified a signature.
But what does this actually look like?
And I mean, I think this is really, really interesting,
actually.
Because Bitcoin lets you specify lots
of different scriptPubKeys and lots of different scriptSigs.
And so this gives you this kind of flexibility
so that you can program in different kinds of conditions
on what it takes to redeem a transaction.
So we're just going to talk about a couple very simple
ones.
Because to get into more complex stuff,
we need to go really deep into this word, script.
So basically the scriptPubKey and the scriptSig
are composed of opcodes.
So Bitcoin has a little less than 200 opcodes,
and you write Bitcoin scripts using these opcodes.
So let's talk about the most common Bitcoin script,
which is Pay to Pubkey Hash.
So the idea here is you want to send money to a public key.
So Alice has Bob's public key, and Alice wants to pay Bob.
And so Alice wants to send money to Bob's public key.
Well, the reason that this is called
pubkey hash, public keys are kind of big,
and there's this nice-- you can kind of make
this nice observation that you don't necessarily
have to put the whole public key in the output.
You can put a hash of the public in the output.
And I think Tadge already talked about this when he was talking
about Bitcoin addresses.
So the scriptPubKey is instructions
on how to verify a signature of a public key that
has been hashed and the scriptSig
is that signature and the actual public key,
the pre-image of the hash public key.
And this is what that looks like.
So this is literally the scriptPubKey
for a Pay to Pubkey Hash input or output,
and this is literally the scriptSig that would you would
use to redeem that output.
So this right here would go inside one of these.
And it would set the conditions under which
you could redeem this output.
And this right here would go inside the input
of the transaction that's redeeming it.
And let's take a look at how this actually works.
So what the Bitcoin Script Interpreter does is,
when it's evaluating whether or not a transaction is valid,
it takes a look at the input, and it
looks at which previous transaction it's looking at
and which index the output is, and it grabs the scriptPubKey.
Well, first of all, it makes sure that output hasn't already
been spent.
Then it grabs the scriptPubKey, and it takes the scriptSig
and it puts them on top of each other, just like this.
So that's the scriptSig up there,
this is the scriptPubKey down here.
And then it runs this combined script
through the Bitcoin Script Interpreter, which
is based on a stack model.
So it starts pushing things onto the stack.
It starts at the very top, and it
starts pushing these items onto the stack and evaluating them.
And so the rules are that constants
get pushed onto the stack--
and then operations-- and these things right here are
operations--
OP_DUP, OP_HASH160, OP_EQUALVERIFY,
and OP_CHECKSIG, these are all Bitcoin opcodes.
Operations have different rules as to how they're evaluated
and what they consume off of the stack.
So the first thing is a signature.
We're going to pop the signature and push it onto the stack
because it is a constant so this would
be the signature that Alice might produce in order
to spend her output.
Then same thing with the pubkey, because the pubkey is also
a constant.
Then we're going to take this first--
now, OK, we're done with constants for the moment,
and the next thing on the stack is OP_DUP.
OP_DUP does basically exactly what it sounds like.
It takes the thing that's currently
on the top of the stack and it duplicates it.
So the way that we consume OP_DUP is we take this pubkey
and we create another copy of the pubkey.
The next op is OP_HASH160.
It also does exactly what it sounds like.
It takes what's on the top of the stack, it hashes it,
and it pushes that hash onto the top of the stack.
So after we run OP_HASH160, this is
what our stack will look like.
Next thing is a constant.
So we take that constant, which should be--
which is the hash of the pubkey.
So this is the address that this money
is being sent to, essentially.
And we put that on the top of the stack.
And then we run this operation called OP_EQUALVERIFY.
Whenever an opcode ends with VERIFY,
it means that it's a little bit special.
It means that it has the ability to, if it fails,
break out of the entire script execution
and immediately cause transaction validation to fail.
So OP_EQUALVERIFY does what it sounds
like, it checks to make sure that the two
things on the top of the stack are equal.
And if they're not equal, then it immediately
fails validation.
So you'll note that what the two things
at the top of the-- let's go back
to what the two things on the top of the stack are right now.
So we pushed the sig, we push a pubkey,
we duplicated that pubkey, and these are from the scriptSig,
so this is from whoever is redeeming the transaction.
So whoever's redeeming the transaction
has put a copy of this pub key on there,
and now that pubkey is on the stack twice.
We hashed the pubkey, and then we
pushed the hash that was specified
in the previous transaction that set up the rules for how
to spend this.
And then OP_EQUALVERIFY makes sure
that these things are actually the same.
And if they're not the same, then it'll
fail that verify check and the entire transaction validation
will abort, and it's an invalid transaction.
So let's assume that they're the same.
OK, great.
Then OP_EQUALVERIFY-- then we continue
transaction validation.
And now we're left with this, OP_CHECKSIG, pubkey, sig.
And this does exactly what you think it might do,
it pops two things off the stack,
checks to make sure that the signature is a valid signature
for this pub key.
And if it is, it pushes true onto the stack.
And if there is a true on top of the stack-- in fact,
I think if there's any constant on top of the stack
when we've consumed all of the parts of our scriptSig
and scriptPubKey, then this returns true
and the transaction is considered valid.
So this is a lot, and I know this is kind of complicated.
So let's sort of step through this one more time.
And there's just a couple of things
that I want to make clear.
This part right here is set up in the output of whatever
transaction we're spending.
So if Alice creates this transaction
and she's spending to Bob, then Alice
would put whose pubkey here?
AUDIENCE: Bob's.
NEHA NARULA: Hash of a pubkey, actually.
Right, so Alice would put the hash of Bob's pubkey here.
And when Bob's redeeming, what would go in the input that
needs to redeem that output?
AUDIENCE: [INAUDIBLE]
NEHA NARULA: Sorry, I can't hear.
AUDIENCE: Bob's signature.
NEHA NARULA: Bob's signature and the pubkey
that corresponds to that signature,
because all we have is a hash.
So those are the things that would
get put on top of the stack.
So up there, we have Bob's signature
and we have Bob's pubkey.
Again, those get pushed onto the stack
because they're constants, duplicated, hash the top,
copy over the hash, make sure that they're equal,
and then check the signature.
And this is a Pay to Pubkey Hash script.
It is the most common script in Bitcoin.
And this is this basically the standard way of spending money.
Are there questions about this?
Yes.
AUDIENCE: Is there a significance
in having that they're equal-verified
before the CHECKSIG?
Because it seems like they're both verifying
tings, and I'm wondering--
NEHA NARULA: Yeah, that's a great question.
So let's say that we didn't have this EQUALVERIFY here then
what could a malicious spender possibly do?
AUDIENCE: Well, I just meant flipping the order.
We're still verifying both, but if you did the CHECKSIG first
versus the EQUALVERIFY first, does that matter?
NEHA NARULA: Oh, that's a good question.
I don't think that would matter.
I'm not sure.
Would it matter?
TADGE DRYJA: You could.
It's faster to verify the two hashes are equal.
The CHECKSIG operation takes a lot of CPU time
so I guess the idea is, if you're going to fail,
fail-- go the easy route.
NEHA NARULA: Yes.
Yes.
AUDIENCE: So are all nodes on the network running this?
NEHA NARULA: Yes.
Every single node on the network is running the Bitcoin Script
Interpreter inside of it.
And the Bitcoin Script Interpreter is known as--
what's called consensus critical.
So if two nodes have slightly different script interpreters
that would interpret this in different ways,
the network would have a consensus failure.
Yes.
AUDIENCE: Why not just Pay to Pubkey?
NEHA NARULA: Pay to Pubkey is a thing, actually.
And Pay to Pubkey Hash is considered better.
And the reason for that is kind of subtle, actually.
It's because-- so the hash of the pubkey
is smaller than the pubkey.
And this is definitely going on the blockchain.
We don't know if this is going to go on the blockchain or not.
Not all outputs are consumed.
So let's put the small stuff here
and the big stuff over here.
It's about saving space.
Also, the set of unspent transaction outputs
is something that every node has to maintain.
It's very important.
You are referring to it quite a bit.
This is not something that every node has to maintain.
And so you want to make this smaller, even
at the expense of making this bigger.
Yes.
AUDIENCE: So then you could accidentally
sign a transaction that has a public key but a script that
doesn't actually verify it?
NEHA NARULA: Could you accidentally
sign a transaction that has a public key but a script that
doesn't verify?
Let me see if this answers your question.
So here is an example of an unspendable output.
The unspendable output has an OP_RETURN
as the first instruction of its scriptPubKey.
OP_RETURN does what you might think
it does, which means when you evaluate it,
it returns immediately and says invalid.
And so if you have one of these in your transaction
in your scriptPubKey, there is no scriptSig
that could possibly redeem the scriptPubKey.
You could create anything you wanted,
and no matter what you put on there,
it would never evaluate to true.
There's no way to actually redeem the scriptPubKey
in this output.
Does that answer your question?
AUDIENCE: I think it's the opposite.
I was asking if you could accidentally get something that
would always evaluate to true.
NEHA NARULA: Ah, OK, well, that's the next slide.
[CHUCKLING]
So yes, this is what's called an anyone-can-spend output.
The simplest anyone-can-spend output
is just an empty scriptPubKey.
Because a scriptSig sig OP_TRUE in it would evaluate to true.
Notice here there's no public keys, there's no signatures,
there's no hashes of public keys.
The scriptPubKey doesn't actually
specify any public keys.
And so-- but when you evaluate this right here,
you'd push OP_TRUE onto the stack,
and then you would finish, and there would be a true--
OP_TRUE would push-- sorry, OP_TRUE
would push a true onto the stack.
And then when you finished, there
would be true on the stack, meaning this is valid.
AUDIENCE: Also another way, you could put the OP_TRUE
in the output script as well.
Then you wouldn't have to push it because--
NEHA NARULA: Yeah.
So this is an anyone-can-spend output,
and this is a no-one-can-spend output.
And there's no public keys in here.
There's no signatures in there.
So you can totally create outputs that have nothing
to do with signatures, or maybe you verify multiple signatures,
which we're not going to go into right now,
but it's also possible.
Yes.
AUDIENCE: Can SIG have a [INAUDIBLE] in it?
NEHA NARULA: Yes.
AUDIENCE: [INAUDIBLE]
NEHA NARULA: Yes, it can.
AUDIENCE: But the list of [INAUDIBLE] are [INAUDIBLE]
NEHA NARULA: There are fewer than 200 opcodes.
The number of standard opcodes is even smaller,
meaning that there's a very small number that you
can use in your scriptSigs and scriptPubKeys.
And it's definitely possible, if you
write some weird scriptPubKey or some weird scriptSig
to accidentally create outputs that are never spendable,
or to accidentally create outputs that
could be spent by someone else.
So there's a standard set of scriptPubKeys to use.
And I would not recommend going outside that set,
except for in the lab that you're going to do,
because we have some more fun ones in there.
Yes.
AUDIENCE: Could you explain a little bit more on the Pay
to Script Hash.
Kind of like what [INAUDIBLE]
NEHA NARULA: Sure, Pay to Script Hash--
I don't actually have slides on Pay to Script Hash,
so I'm not sure that we can do a good job of explaining it
right now.
But the idea behind Pay to Script Hash is that--
yeah, I don't have the slides for it.
But the idea is that you're going to put, instead
of this particular scriptPubKey here,
you're going to have a scriptPubKey that
includes a hash of a script.
And then the scriptSig has to produce that script,
and it has to match that hash, and the whole thing
has to verify is the rough idea behind Pay to Script Hash.
And we can produce an example of that for you tomorrow.
But the cool thing about that is you
don't even know what you have to do to redeem this output.
So someone has to produce a script that has the same hash,
and when combined with the scriptPubKey,
will evaluate to true.
AUDIENCE: And that script would be pushed on the stack?
NEHA NARULA: Yeah, so the scriptSig and the scriptPubKey
literally just get concatenated together
and then evaluated as one thing.
So yeah, it would just go through the same thing.
Any more questions?
So what do you guys think?
Is this good?
Is this bad?
AUDIENCE: Could you try to [INAUDIBLE]
NEHA NARULA: Yeah, that's a great question.
So the question is, could you DDoS a network
by creating transactions that are not spendable?
AUDIENCE: So you still [INAUDIBLE]
NEHA NARULA: You can't really DDoS the network, per se.
So this is an example of a transaction
that's not spendable.
And see how it has this OP_RETURN, and it says,
whatever.
There is this pattern of people who
like to store things in the Bitcoin blockchain,
because it's there, and it's very highly replicated.
And so one type of transaction that a lot of people make
is and OP_RETURN with a hash of some data in it
or some data in it.
These are unspendable outputs that
will live on the Bitcoin blockchain forever,
and will be part of the UTXO set, possibly forever.
Generally, Bitcoin developers discourage
using Bitcoin in this way because it
does bloat the UTXO set.
That said, there's nothing to prevent you from doing it
if you want to pay the fees.
What?
TADGE DRYJA: It's actually not part of the UTXO set
because it has the OP_RETURN.
NEHA NARULA: Oh, really?
I didn't know that.
OK, I didn't know that they weren't kept in the UTXO set.
TADGE DRYJA: [INAUDIBLE] they would just
made [INAUDIBLE] key hash into whatever [INAUDIBLE]
and that would bloat the UTXO set.
So it's like, well, this is not [INAUDIBLE]
NEHA NARULA: OK, I didn't know that those
weren't included in the UTXO.
So that's good.
So then it doesn't boat the UTXO set,
it just goes in the blockchain.
And you paid the fee to put your transaction in the blockchain.
So good for you.
Yes.
AUDIENCE: What's the architectural logic
for having a specific set of opcodes that Bitcoin can run?
Why not use a more general programming language?
Is it just to have control?
NEHA NARULA: That's a great question.
So why have this weird Op code thing, right?
I mean, what kind of sense does this make?
So the problem with the general programming language
is it's really easy to shoot yourself in the foot.
It's really easy to write a program that you think--
how many of you have had a bug in your program ever?
Please, all of you should probably
raise their hands, right?
[CHUCKLING]
And how many of you have had bugs in your program
that showed up a lot later than you thought they would,
when you thought your program didn't have any bugs?
So these things, once you put them out there,
these scriptPubKeys and script tag,
once you put these transactions out there, they're out there.
You cannot take them back--
well, not easily.
And they might execute in ways that you didn't
anticipate them executing.
The more complicated the script you write, the more likely
it is that there's some hole in your script, some way
of satisfying it that you didn't anticipate,
that could end up stealing your money.
So with a general programming language,
well, you might think, oh, well, these OP codes
are super tricky and weird, and I don't understand them,
at least with the general programming language,
I'm more likely to write correct things, right?
Eh.
[CHUCKLING]
Actually, having this strange opcode language
has a lot of benefits.
So number one, it's not Turing-complete.
You know exactly how much CPU it is
going to take to run these scripts because
of the nature of the opcodes and the language.
There's no FOR loops in here.
You know you can't just run a WHILE that takes forever.
This is a stack-based language.
And so it's very easy to tell how long a transaction is
actually going to take to execute.
And this is really important, because every node
in the network has to execute these things.
So you don't want a script sneaking in there that's
going to take hours to execute.
It's also-- you can look at the number of opcodes
in the script, and like I said, get a rough sense of how
expensive it's going to be.
And that's why there are limits on the number of opcodes
you can have in a script.
It's very difficult to do that if you have a more
general programming language.
So those are a couple of reasons.
And I mean, I think it's important to point out
that Ethereum, which does have a more general programming
language, there are constantly problems popping up
where people are taking advantage of transact
of contracts, even fairly well-understood ones--
or we thought they were well understood--
and figuring out how to freeze people's funds
or steal people's funds.
So that's the motivation behind this sort
of strange, stack-based opcode language.
Are there any other questions?
Yeah, back there.
AUDIENCE: You talked about unspendable transactions
outputs.
NEHA NARULA: Outputs, Yes.
AUDIENCE: Could you comment on colored coins?
NEHA NARULA: Oh, colored coins--
no comment on colored coins.
I don't understand them well enough
to talk about them right now.
Yeah.
What did you--
TADGE DRYJA: I would say one other thing.
Most of the-- a lot of the cool opcodes are disabled.
So it's very limited.
It seems like you--
there's a list of, here's all these opcodes.
Oh, I can multiply numbers together.
That's disabled.
[INAUDIBLE]
NEHA NARULA: Yeah.
And I do want to stress, when you're dealing with real
money-- so not in the lab for this class--
you want to stick with very standard scripts.
You don't want to write super-crazy, weird, tricky
scripts, or if you do, you want to get
them vetted very carefully.
Yes.
AUDIENCE: Who is disabling and enabling these things?
NEHA NARULA: Great question.
So there are two levels at which things can be
enabled or disabled in Bitcoin.
So first, there's the validation rules,
so what makes a transaction valid or not valid.
Meaning that if a transaction is invalid and it's in a block,
that whole block is invalid.
If a transaction is invalid and in a block, and that block
is in a blockchain, that entire blockchain is invalid.
So there's that level.
And we're going to talk about how those rules change
and who sets those rules.
But you can consider them sort of, for now,
being set by the code, the Bitcoin Core--
or the Bitcoin software, which specifies what is valid
and what is invalid.
But there is another level at which
you can adjust what ends up getting accepted
or not accepted.
And that is what is transmitted over the peer-to-peer network.
So there are transactions that are valid, but are
what's known as non-standard.
And that transaction, if it gets into a block,
that block is still valid.
But the nodes in the network, if it sees that transaction,
won't relay them around.
So you'd have to be a miner and actually decide,
I want this transaction in a block, and mine that block.
And if you do that, everyone will consider
it a valid block, OK, fine.
But no one will actually send your transaction around.
And so if you're not a miner yourself,
the odds of it getting into the blockchain are very low.
And so those are the two sets of rules.
The peer-to-peer rules are more restrictive than the validation
rules.
OK, so we already kind of started
talking about this a little bit--
what are the benefits of your UTXOs
and what are the downsides of UTXOs?
So one of the benefits of UTXOs is that--
do you guys see how they help with replay attacks?
Sure, I can copy this transaction
and put multiple out there, but you're only allowed
to spend an output once.
And once you consume that output, that's it.
So you can't really do replay attacks in this model.
So it's a very sort of elegant way
of getting rid of the replay attack
problem without having to store a nonce per account
in your system.
Another benefit is that you can actually
get a little bit better privacy with this UTXO system.
Because you don't have to use the same public key
for all of your transactions.
You can generate new ones every single time,
and then combine UTXOs from different things into--
I mean, you're going to have to combine them anyway,
even if they did spend at the same public key.
So why not generate fresh ones all the time?
And it becomes a little bit harder
to track who you're spending and who you're paying to.
In the account-based model, you need to have--
it's more likely that all of your funds
are going to be in one account in order to make a spend.
Now a downside of UTXOs is that they're complicated.
So when I first heard about UTXOs
and I first understood how Bitcoin worked, I was like,
why does Bitcoin work this way?
This makes zero sense.
An account-based model would be so much easier.
And I mean, I think, for wallet providers
and for people who are writing user software,
it is easier to deal with an account-based model than a UTXO
model.
Because people who are writing Bitcoin wallet software
have to keep track of all of your UTXOs
and then figure out how to combine them
to get the amount that you want to spend,
and make sure that they produce what are called change outputs
the right way, so you don't accidentally
lose some of your money because you're
spending an output that has 100 bitcoin
but you're only paying someone one bitcoin.
You better make sure you have that 99 bitcoin output in there
going back to you.
So it just makes everything a little bit more complicated.
You can't just spend the amount you want to spend.
You have to find these outputs, and combine them
in the right way, and figure all of this stuff out.
Another problem is around fungibility.
So this is why I say that bitcoin is not fungible,
because of these outputs, and the fact that you have
to point back to the output that you're going to spend,
which ends up creating what's called a transaction graph.
So you can sort of see how things are chained together,
and you can actually discern quite a bit of information
about what's going on in the network.
And in fact, the FBI has used the transaction graph
in some of its cases around Silk Road,
to see where Bitcoin was moving.
And there are many companies out there--
Chain Analysis, Elliptic, that provide services
based around the fact that Bitcoin's transaction graph is
totally open, and so you can see how coins are moving around.
So in addition to the transaction graph problem,
you kind of lose this aspect of fungibility in the sense
that, let's say, that I know that, for whatever reason,
these coins came from, let's say, I don't know,
a terrorist or something like that.
You then know exactly where those coins are going,
and you can kind of see the chain of transactions
that come off of those coins.
And it sort of creates a potential opportunity
for someone to blacklist coins.
Or you might decide that you like coins that were produced--
that are fresher than other coins.
So there's this ability to distinguish between coins,
which is a little bit troublesome,
because fungibility is generally considered
a very good property for money to have,
and this is not entirely fungible.
But people are working on that.
Any other questions?
I alluded to this earlier, but every single node
that's running the Bitcoin software
keeps this data structure called the UTXO set.
So these are all of the outstanding, unspent
transaction outputs.
It's all of the coins in the system, all
of the money in the system that's available to be spent.
The way that this is computed is,
when a Bitcoin node comes online and starts
to download the blockchain, they run through the blockchain
and continuously add and remove things
from the UTXO set to produce a UTXO
set that is valid for whatever the last block is
that it's seen.
When a new block comes in, a node runs through the block,
and again removes and adds things
to the UTXO set as necessary.
Right now, there's about 60 million UTXOs in the UTXO set.
A lot of them, unfortunately-- well, a lot,
in terms of bytes of the UTXO set, a lot of them
are very small and are unlikely to get spent very soon.
So that's kind of a bummer.
The UTXO set is about three gigabytes right now, I think.
And so every node in Bitcoin, in addition
to storing the blockchain, stores this UTXO set,
and uses this data structure to very quickly tell
if a transaction is a double-spend or not.
Any questions about the UTXO set?
Yes, SJ.
AUDIENCE: How do you avoid having small transactions
accumulate over time?
NEHA NARULA: That's a good question--
how do you avoid having small transactions accumulate
over time?
I don't know the answer to that question.
It's kind of a bummer.
It's not really in people's interest
to generate those transactions because you're creating--
I haven't talked about how fees are computed yet.
But fees are measured according to the resources
that a transaction takes up in the system.
Fees are measured according to the size of the transaction.
So if you have to combine a whole bunch of tiny outputs
in order to get a big enough sum,
you're going to have to pay more in fees.
So it's not really in your interest
to produce a lot of these tiny things.
But there's not really a good way of stopping it.
And in fact there have been services in the past,
like Satoshi dice and whatnot, that
have created a ton of very tiny outputs
and it bloated the UTXO set.
I don't know, Tadge, if you have any insight into how
to stop that from happening.
TADGE DRYJA: Make the fees higher.
NEHA NARULA: Other than the fees--
other than the fees, yeah.
TADGE DRYJA: Better wallet software.
A lot of it's [? unintentional. ?]
NEHA NARULA: Yes.
AUDIENCE: You mentioned that one other [INAUDIBLE] is privacy,
and you need to generate new pubkeys.
But would this prevent you, in the account-based model,
prevent from getting an account?
NEHA NARULA: Yeah.
So I'm not sure in the account-based model--
we'll find out more about this when we get to the Ethereum
section of the class--
how you combine spending from different accounts.
But Bitcoin makes it very easy to combine spending
from different pubkeys.
In the account-based model, I could
imagine it being a slightly more complicated process.
But that's a good point.
Yes, you could definitely create a lot of accounts
with a lot of small balance.
But if you want to spend a lot, you're
going to have to somehow accumulate
all of that spending.
Remember, I talked about how there
is one special transaction in every block, called
the coinbase transaction.
And this transaction does not have
to follow all of the rules specified before.
So this is kind of like a hard-coded exception
into how Bitcoin works, that there
can be this one transaction in every block,
called the coinbase transaction.
It is the first transaction.
The coinbase transaction has exactly one input.
And that input needs to have certain feel.
This input does not point to a previous output.
This input is essentially empty.
This is the transaction that doles out the block reward.
So this is the transaction that--
the block reward used to be 50 bitcoins--
25 bitcoins, 50 bitcoins, now it's 12.5 bitcoins per block.
This is the transaction that doles out that 12.5 bitcoins
plus the fees of the block.
So it has exactly one input.
And that input has all zeros for the previous transaction ID.
And then FFFFF for the index into that previous transaction
ID.
I think the scriptSig can basically be whatever you want.
It's not evaluated.
It might have to be valid.
I'm not sure.
And then its output is in Satoshis.
So this is 12.5 Bitcoin.
Because remember, a Bitcoin is 10 to the eighth Satoshis.
So this is 12.5 bitcoin, plus here
are the fees from that block.
And you probably, if you're the one--
so the miner is the one who creates this transaction.
And the miner who creates this transaction probably
wants to give themselves the Bitcoin and the block reward,
and so would specify, in here, a scriptPubKey
that they could redeem.
Note that this also has the nice property of making--
well, I don't if it's a nice property,
but all the blocks that people work on are actually different.
Because in each block, the coinbase transaction
is going to be different because each person is
trying to pay themselves for-- the different miners.
Yes.
AUDIENCE: What's [INAUDIBLE] them to 12.5 bitcoins?
NEHA NARULA: Ah, great question.
So what would happen if a miner put,
like, 100 bitcoins in there?
Any idea?
So what's keeping that at 12.5 bitcoins
is the same thing that's keeping invalid transactions out
of the blockchain, which is the consensus rules of Bitcoin.
It says in the code that, at this point in time, given
the block height where we are, that number
should be no larger than 12.5 plus the fees
in the transaction.
And if a miner put a different number in there--
they can put a lower number, that's fine.
They'll end up burning some Bitcoin, which is unfortunate.
But if they try to put something higher in there,
the network will regard it as invalid,
because the network is running a set of rules.
And we are, in this class, going to get
to what happens when you want to change that set of rules, which
gets really tricky.
But right now, assume that the network
is running the set of rules, they're all checking,
they're all validating.
And so the answer is, the network
would reject this block if there was a higher number in there.
So this is kind of fun, because you can sort of
put whatever you want in here.
And so miners like to put advertisements in there.
And there actually was a period, there was a time--
I don't know if you can still do this--
where you could literally buy this space from miners,
and put whatever you wanted in there.
So you could put your name, or ask someone to marry you,
or whatever you might want to do,
to put in the Bitcoin blockchain for all eternity.
But yeah, so miners like to put fun things in the scriptSig.
And maybe we could show them some of those things later.
Or you could go look yourself.