Bitcoin - Transaction block chains

WEBVTT
Kind: captions
Language: en

00:00:00.500 --> 00:00:02.790
The last really essential
or salient piece

00:00:02.790 --> 00:00:05.710
for understanding the
mechanics of how Bitcoins work

00:00:05.710 --> 00:00:09.630
is what we call the
transaction block chain.

00:00:09.630 --> 00:00:11.360
So if you recall in
the previous video,

00:00:11.360 --> 00:00:13.740
you had a motivating
example of a user, Alice,

00:00:13.740 --> 00:00:17.710
who wanted to send
some number of Bitcoins

00:00:17.710 --> 00:00:19.310
to another user,
Bob, in the system.

00:00:19.310 --> 00:00:22.760
And what Alice has to do to
initiate that transaction was

00:00:22.760 --> 00:00:25.910
to construct a transaction--
a record of sorts-- that

00:00:25.910 --> 00:00:28.460
contained information
about the transaction

00:00:28.460 --> 00:00:32.159
and that was signed with
Alice's signing key.

00:00:32.159 --> 00:00:35.500
And that actually contained
Alice's public verification key

00:00:35.500 --> 00:00:38.670
and Bob's public
verification key as well.

00:00:38.670 --> 00:00:42.580
And that transaction information
was basically broadcast out,

00:00:42.580 --> 00:00:46.380
as we mentioned, to the
entire Bitcoin ecosystem.

00:00:46.380 --> 00:00:50.640
To all the nodes on the
Bitcoin peer-to-peer network.

00:00:50.640 --> 00:00:52.880
And the various nodes
in the Bitcoin ecosystem

00:00:52.880 --> 00:00:53.920
are going to sit there.

00:00:53.920 --> 00:00:55.680
They're going to
receive information

00:00:55.680 --> 00:00:57.601
about this transaction.

00:00:57.601 --> 00:00:59.600
But they're also going
to be getting information

00:00:59.600 --> 00:01:00.975
about a lot of
other transactions

00:01:00.975 --> 00:01:03.765
that are taking place
around the same time.

00:01:03.765 --> 00:01:05.640
And what these notes
are going to start doing

00:01:05.640 --> 00:01:09.290
is they're going to work on
incorporating this transaction

00:01:09.290 --> 00:01:12.760
record into a ledger of all
transactions that have ever

00:01:12.760 --> 00:01:15.304
taken place in the
Bitcoin system.

00:01:15.304 --> 00:01:17.720
And so what happens is that
each node basically starts off

00:01:17.720 --> 00:01:21.791
by taking all of the previously
unincorporated transactions

00:01:21.791 --> 00:01:22.915
that they've ever received.

00:01:22.915 --> 00:01:25.415
So there's going to be all these
transactions out there that

00:01:25.415 --> 00:01:27.960
have kind of happened
within a given time window.

00:01:27.960 --> 00:01:30.260
And there's all these
Bitcoin transactions kind

00:01:30.260 --> 00:01:31.460
of floating around.

00:01:31.460 --> 00:01:35.591
And these nodes-- these Bitcoin
miners as they're called--

00:01:35.591 --> 00:01:37.340
are going to receive
information about all

00:01:37.340 --> 00:01:39.050
these different
transactions and they're

00:01:39.050 --> 00:01:40.675
going to start working
on incorporating

00:01:40.675 --> 00:01:42.010
those transactions.

00:01:42.010 --> 00:01:47.450
And their first goal is to
collate these transactions

00:01:47.450 --> 00:01:49.840
into what's known as
a transaction block.

00:01:49.840 --> 00:01:52.420
So if you recall
our ledger analogy,

00:01:52.420 --> 00:01:55.270
a single Bitcoin
transaction essentially

00:01:55.270 --> 00:01:59.460
corresponds to a proposed
entry in a ledger.

00:01:59.460 --> 00:02:02.050
In that capacity,
a transaction block

00:02:02.050 --> 00:02:05.360
would basically correspond
to her page in a ledger

00:02:05.360 --> 00:02:07.610
where you have multiple
transactions that

00:02:07.610 --> 00:02:10.669
are listed in that
page of the ledger.

00:02:10.669 --> 00:02:14.680
And the goal-- the Bitcoin
miner's goal-- is to really,

00:02:14.680 --> 00:02:17.380
essentially, to take
that page and get it

00:02:17.380 --> 00:02:20.580
added to the global ledger book,
the global comprehensive ledger

00:02:20.580 --> 00:02:21.755
book.

00:02:21.755 --> 00:02:24.130
Now to engage in this sort of
work, what these nodes will

00:02:24.130 --> 00:02:27.230
basically do is they'll first
take all the transactions that

00:02:27.230 --> 00:02:28.430
have been broadcast out.

00:02:28.430 --> 00:02:29.971
And let's say these
four transactions

00:02:29.971 --> 00:02:31.440
have been broadcast out.

00:02:31.440 --> 00:02:33.780
And they're going to basically
hash these transactions

00:02:33.780 --> 00:02:37.692
in pairs in basically
a tree-like structure.

00:02:37.692 --> 00:02:39.150
They'll take these
two transactions

00:02:39.150 --> 00:02:41.135
and they'll apply a
[? graphic ?] hash function

00:02:41.135 --> 00:02:42.310
to those details.

00:02:42.310 --> 00:02:44.530
And we'll get a
[? cars ?] flying digest,

00:02:44.530 --> 00:02:46.405
goes the same for these
two, and then they'll

00:02:46.405 --> 00:02:48.200
take these two
digests and hash them

00:02:48.200 --> 00:02:51.020
to get a single digest value.

00:02:51.020 --> 00:02:57.320
And this digest effectively
encodes all of the transactions

00:02:57.320 --> 00:02:59.530
that were previously
unincorporated

00:02:59.530 --> 00:03:03.810
and that were received by
these individual nodes.

00:03:03.810 --> 00:03:05.460
And then this
digest is basically

00:03:05.460 --> 00:03:10.110
going to be combined with
the hash of the transaction

00:03:10.110 --> 00:03:12.460
block that was previously
accepted by the network.

00:03:12.460 --> 00:03:14.770
So you can imagine if
there is-- the network

00:03:14.770 --> 00:03:16.946
will have a series
of transaction blocks

00:03:16.946 --> 00:03:18.195
that were previously accepted.

00:03:18.195 --> 00:03:20.200
And in fact, every
transaction block

00:03:20.200 --> 00:03:22.541
as I mentioned just
now incorporates

00:03:22.541 --> 00:03:23.790
the previous transaction lock.

00:03:23.790 --> 00:03:25.800
So this transaction
block will incorporate

00:03:25.800 --> 00:03:28.419
the one that was
used just before it,

00:03:28.419 --> 00:03:30.210
and this transaction
block will incorporate

00:03:30.210 --> 00:03:31.626
the one that was
used just for it.

00:03:31.626 --> 00:03:33.030
And it's going to
go on literally

00:03:33.030 --> 00:03:35.270
until the beginning
of Bitcoin times.

00:03:35.270 --> 00:03:37.640
So this is really
where the Bitcoin--

00:03:37.640 --> 00:03:40.416
the beginning of time for
the Bitcoin system, this

00:03:40.416 --> 00:03:45.250
is just time equals
zero for Bitcoin.

00:03:45.250 --> 00:03:47.430
And they're going to
take this last block

00:03:47.430 --> 00:03:49.380
and they're going
to, essentially now,

00:03:49.380 --> 00:03:54.810
take this last block and combine
it with this most recent block.

00:03:54.810 --> 00:03:57.780
And so if you imagine that
you have now, not just

00:03:57.780 --> 00:04:00.930
an individual block, because
each individual block

00:04:00.930 --> 00:04:02.330
incorporates the
block before it.

00:04:02.330 --> 00:04:05.120
We're not dealing anymore with
an isolated or distinct block

00:04:05.120 --> 00:04:09.060
of transactions, but rather
with a chain of blocks

00:04:09.060 --> 00:04:12.320
that starts literally at the
beginning of the entire Bitcoin

00:04:12.320 --> 00:04:13.940
system.

00:04:13.940 --> 00:04:15.642
Now when you do all
of this combination,

00:04:15.642 --> 00:04:17.100
at the end of the
day, you're going

00:04:17.100 --> 00:04:19.420
to do some cryptographic
hashing and you basically

00:04:19.420 --> 00:04:21.279
will end up with a
sequence of numbers.

00:04:21.279 --> 00:04:22.654
And this sequence
of numbers will

00:04:22.654 --> 00:04:25.930
be derived by incorporating
all these blocks together.

00:04:25.930 --> 00:04:27.470
You'll get a
sequence of numbers,

00:04:27.470 --> 00:04:28.970
and what we're going
to basically do

00:04:28.970 --> 00:04:32.750
is take this sequence of numbers
and convert that sequence

00:04:32.750 --> 00:04:38.020
of numbers into a challenge
in a proof of work protocol.

00:04:38.020 --> 00:04:40.130
Now I did a separate video
on proof of protocols,

00:04:40.130 --> 00:04:41.880
I would encourage you
to watch that if you

00:04:41.880 --> 00:04:44.525
want to get a better
sense for how they work.

00:04:44.525 --> 00:04:48.730
But the short of it is that
what the Bitcoin mining node has

00:04:48.730 --> 00:04:52.490
to do at this point is he'll
take that Bitcoin-- he'll take

00:04:52.490 --> 00:04:54.310
the challenge and
he'll have to come up

00:04:54.310 --> 00:04:57.380
with a separate sequence of
numbers-- which we typically

00:04:57.380 --> 00:05:00.314
termed the proof, or
the proof of work--

00:05:00.314 --> 00:05:01.730
and this proof of
work has to have

00:05:01.730 --> 00:05:03.375
a very specific
mathematical property.

00:05:03.375 --> 00:05:05.000
And what that
property entails is

00:05:05.000 --> 00:05:07.295
that if you take the
challenge numbers,

00:05:07.295 --> 00:05:08.670
and you take these
proof numbers,

00:05:08.670 --> 00:05:10.570
and you concatenate
them together,

00:05:10.570 --> 00:05:14.010
and you make them the input
to a cryptographic hash

00:05:14.010 --> 00:05:17.290
function, the
resulting output has

00:05:17.290 --> 00:05:21.000
to have a large prefix
of zeroes And that

00:05:21.000 --> 00:05:23.220
doesn't have to be all
zeroes, but a large portion

00:05:23.220 --> 00:05:29.140
of the beginning-- the
prefix-- has to be all zeroes

00:05:29.140 --> 00:05:31.330
And if you think about
for a moment, given

00:05:31.330 --> 00:05:32.840
that cryptographic
hash functions,

00:05:32.840 --> 00:05:36.540
given that their output
tends to look fairly random,

00:05:36.540 --> 00:05:38.950
it's unlikely in
any given instance

00:05:38.950 --> 00:05:41.764
that you are going
to see a proof.

00:05:41.764 --> 00:05:43.180
A proposed proof
that provides you

00:05:43.180 --> 00:05:45.860
with a large string of
zeroes at the beginning.

00:05:45.860 --> 00:05:49.030
And so what the Bitcoin miner
will have to do is on average,

00:05:49.030 --> 00:05:50.970
he'll have to try out
many possible choices

00:05:50.970 --> 00:05:54.335
for these proof numbers
until he finally gets lucky

00:05:54.335 --> 00:05:55.710
and he stumbles
upon one that has

00:05:55.710 --> 00:06:00.050
this kind of off-beat or
strange statistical property.

00:06:00.050 --> 00:06:02.980
And the actual difficulty of
finding these proof numbers,

00:06:02.980 --> 00:06:06.160
as you can tell, is
dependent on exactly how

00:06:06.160 --> 00:06:08.700
many leading zeroes
are required.

00:06:08.700 --> 00:06:12.700
The more leading zeroes
you require in this proof,

00:06:12.700 --> 00:06:14.925
the longer it takes to
actually solve a problem.

00:06:14.925 --> 00:06:17.230
The longer it takes to
actually come up with a proof

00:06:17.230 --> 00:06:19.580
that works with respect
to a given challenge.

00:06:19.580 --> 00:06:21.220
The fewer zeroes
that you require,

00:06:21.220 --> 00:06:22.670
the less time it will take.

00:06:22.670 --> 00:06:26.299
Now the exact number of
bits of zero bits required

00:06:26.299 --> 00:06:28.590
in the Bitcoin protocol
actually does change over time.

00:06:28.590 --> 00:06:29.920
It gets calibrated.

00:06:29.920 --> 00:06:32.400
And it's designed
to not, on average,

00:06:32.400 --> 00:06:35.840
the average time taken
across the whole system

00:06:35.840 --> 00:06:38.200
should be about 10 minutes.

00:06:38.200 --> 00:06:41.970
So you want to take about 10
minutes for at least one node

00:06:41.970 --> 00:06:45.160
to come up with a valid
proof, but keep in mind

00:06:45.160 --> 00:06:48.570
that a lot of nodes are working
on this proof concurrently.

00:06:48.570 --> 00:06:50.960
All right, now once this
proof of work is found,

00:06:50.960 --> 00:06:54.960
let's say that the proof of
work is eventually found.

00:06:54.960 --> 00:06:57.360
The Bitcoin miner will
announce the results

00:06:57.360 --> 00:06:58.912
to the overall
peer-to-peer network.

00:06:58.912 --> 00:07:01.370
He's going to take this proof
and really all the challenge,

00:07:01.370 --> 00:07:03.982
and so on, and he's going to
announce it to all the notes.

00:07:03.982 --> 00:07:05.940
And they're now going to
see that, hey, there's

00:07:05.940 --> 00:07:07.660
this proof out there,
somebody found it.

00:07:07.660 --> 00:07:09.420
Let's drop the other
stuff we were doing

00:07:09.420 --> 00:07:12.230
and we're going to now
start to work and build

00:07:12.230 --> 00:07:13.510
on top of this new proof.

00:07:13.510 --> 00:07:16.160
Remember, this new proof of
this new challenge, these all

00:07:16.160 --> 00:07:18.722
incorporate all the
previous transaction blocks.

00:07:18.722 --> 00:07:20.180
Really, what they're
starting to do

00:07:20.180 --> 00:07:25.550
is starting to work off of a
new, updated transaction block

00:07:25.550 --> 00:07:27.100
chain.

00:07:27.100 --> 00:07:30.010
And they're going to incorporate
any new unincorporated

00:07:30.010 --> 00:07:32.742
transactions into that
new transaction blocking.

00:07:32.742 --> 00:07:34.950
Now there are a couple of
points I want to make here.

00:07:34.950 --> 00:07:38.380
So first of all, as part of
constructing these transactions

00:07:38.380 --> 00:07:40.610
blocks, and really as
part of incorporating them

00:07:40.610 --> 00:07:44.040
into a transaction block
chain, Bitcoin miners

00:07:44.040 --> 00:07:48.320
are actually allowed--
one little special treat--

00:07:48.320 --> 00:07:53.210
they are allowed to include
in that transaction block--

00:07:53.210 --> 00:07:54.750
a special node for themselves.

00:07:54.750 --> 00:07:57.260
And this node will
basically be a little reward

00:07:57.260 --> 00:08:00.774
if they can get-- and
let me use the greenish

00:08:00.774 --> 00:08:02.190
color for that
reward-- they could

00:08:02.190 --> 00:08:06.520
take the first block,
the first transaction

00:08:06.520 --> 00:08:09.247
item, the first
transaction record,

00:08:09.247 --> 00:08:11.330
and they can put in that
transaction record-- they

00:08:11.330 --> 00:08:14.570
can assign a reward
to themselves.

00:08:14.570 --> 00:08:18.170
Now the amount of that
reward will change over time.

00:08:18.170 --> 00:08:21.630
But I do want to point out what
this transaction is typically

00:08:21.630 --> 00:08:27.060
called is called a coin-based
transaction, or a generation

00:08:27.060 --> 00:08:27.740
transaction.

00:08:27.740 --> 00:08:31.810
This is how new coins get
included in the Bitcoin system.

00:08:31.810 --> 00:08:34.890
So whenever a minor
succeeds in coming up

00:08:34.890 --> 00:08:38.710
with a proof as part of
that he'll have been allowed

00:08:38.710 --> 00:08:41.419
to come up with his own
transaction to reward himself,

00:08:41.419 --> 00:08:43.299
a special little
reward, for extending

00:08:43.299 --> 00:08:45.960
the effort necessary to
come up with this proof

00:08:45.960 --> 00:08:49.390
and for doing all this
work associated with adding

00:08:49.390 --> 00:08:53.070
a new transaction block to
the existing transaction

00:08:53.070 --> 00:08:55.281
block chain for Bitcoin.

00:08:55.281 --> 00:08:56.530
And I think that's reasonable.

00:08:56.530 --> 00:09:00.020
After all these notes are using
a lot of computational power

00:09:00.020 --> 00:09:04.095
to come up with these
proofs and if they're

00:09:04.095 --> 00:09:05.970
using computational
power that must mean that

00:09:05.970 --> 00:09:07.386
somewhere along
the line, somebody

00:09:07.386 --> 00:09:09.584
is spending money on
electricity and so on.

00:09:09.584 --> 00:09:11.500
Now, I also want to point
out that in addition

00:09:11.500 --> 00:09:15.330
to this coin-base
award, the nodes who're

00:09:15.330 --> 00:09:17.780
doing the Bitcoin mining,
the ones who succeed.

00:09:17.780 --> 00:09:19.680
Also get to collect
the transaction

00:09:19.680 --> 00:09:21.850
fees that were specified
in the transaction records.

00:09:21.850 --> 00:09:26.115
If you recall, a person issuing
a transaction in Bitcoin

00:09:26.115 --> 00:09:30.310
can allocate or set aside a
certain amount of money-- maybe

00:09:30.310 --> 00:09:32.590
it can be a Bitcoin or
a fractional Bitcoin--

00:09:32.590 --> 00:09:36.570
for the node who
succeeds in coming up

00:09:36.570 --> 00:09:38.145
with the actual
proof of working,

00:09:38.145 --> 00:09:40.740
and effectively the
node that succeeds

00:09:40.740 --> 00:09:42.310
in being able to
add that transaction

00:09:42.310 --> 00:09:45.930
to the overall bitcoin
transaction block chain.

00:09:45.930 --> 00:09:47.810
And so that node that
does the work succeeds,

00:09:47.810 --> 00:09:49.970
gets a reward, another
transaction fee.

00:09:49.970 --> 00:09:52.510
Now this could actually
become quite large

00:09:52.510 --> 00:09:56.071
because the node will not
only get the transaction

00:09:56.071 --> 00:09:57.195
fee before one transaction.

00:09:57.195 --> 00:10:00.372
You'll get the transaction
fee for all the transactions

00:10:00.372 --> 00:10:01.830
that appeared in
the current block.

00:10:01.830 --> 00:10:03.538
It's going to give
the aggregate over all

00:10:03.538 --> 00:10:06.512
these different transactions.

00:10:06.512 --> 00:10:07.970
Now the second
point I want to make

00:10:07.970 --> 00:10:11.250
is that it might be
possible for two nodes

00:10:11.250 --> 00:10:13.750
to solve the proof of work
independently of each other.

00:10:13.750 --> 00:10:16.090
And somehow, they
both end up trying

00:10:16.090 --> 00:10:18.460
to add to that existing
chain in some ways.

00:10:18.460 --> 00:10:21.240
You make get some weird
chain forking happening.

00:10:21.240 --> 00:10:24.230
If that happens, the peers
in the Bitcoin network

00:10:24.230 --> 00:10:29.521
will basically break a tie
by sticking with the longest

00:10:29.521 --> 00:10:30.020
chain.

00:10:30.020 --> 00:10:31.800
And by longest, I
don't mean the one

00:10:31.800 --> 00:10:34.280
that has to be the most
transactions in it.

00:10:34.280 --> 00:10:37.280
I really need the one
that has the highest

00:10:37.280 --> 00:10:39.925
aggregate difficulty
associated with that underlying

00:10:39.925 --> 00:10:43.640
proof of work protocol in each
of the transaction blocks.

00:10:43.640 --> 00:10:46.300
And we'll basically look at
the total amount of effort

00:10:46.300 --> 00:10:49.210
that was required to generate
that chain with regard

00:10:49.210 --> 00:10:50.270
to that proof of work.

00:10:50.270 --> 00:10:53.779
And whichever chain has
the most work associated

00:10:53.779 --> 00:10:55.320
with it is a chain
that's sacrosanct,

00:10:55.320 --> 00:10:57.566
it's a chain that
everybody will accept.

00:10:57.566 --> 00:10:59.190
Now you may get some
word discrepancies

00:10:59.190 --> 00:11:01.040
because of network
latency issues and so on.

00:11:01.040 --> 00:11:04.010
But the idea is that after maybe
a couple of rounds when there

00:11:04.010 --> 00:11:06.130
are ties, they'll quickly
resolve themselves

00:11:06.130 --> 00:11:08.350
as long as most of the
nodes are being honest

00:11:08.350 --> 00:11:12.589
and really stick to the
implementation of the protocol.

00:11:12.589 --> 00:11:14.630
Now since Bitcoin miners
are generating bitcoins,

00:11:14.630 --> 00:11:17.046
I think there's an interesting
question that comes up here

00:11:17.046 --> 00:11:19.890
which is, how is the Bitcoin
money supply, controlled,

00:11:19.890 --> 00:11:20.830
and how is it managed?

00:11:20.830 --> 00:11:25.170
And I'm going to talk about that
concept in a subsequent video.


Bitcoin - Proof of work

WEBVTT
Kind: captions
Language: en

00:00:00.780 --> 00:00:03.540
A proof of work protocol
is a vehicle really

00:00:03.540 --> 00:00:05.290
by which somebody
can effectively

00:00:05.290 --> 00:00:07.730
prove to you that
they've engaged

00:00:07.730 --> 00:00:11.730
in a significant amount
of computational effort.

00:00:11.730 --> 00:00:14.380
Proof of work protocols
often amount to puzzles.

00:00:14.380 --> 00:00:17.950
And these puzzles that
can, on the one hand,

00:00:17.950 --> 00:00:20.190
be challenging to
solve-- and by that

00:00:20.190 --> 00:00:23.740
I mean they require some
serious computational effort

00:00:23.740 --> 00:00:26.040
and really can't be
short circuited--

00:00:26.040 --> 00:00:28.730
but on the other hand,
that effort can actually

00:00:28.730 --> 00:00:33.900
be easily verified, and it can
be verified in far less time

00:00:33.900 --> 00:00:37.362
than it took to conduct that
effort in the first place.

00:00:37.362 --> 00:00:38.180
OK.

00:00:38.180 --> 00:00:40.720
And there are a number of
applications of such protocols.

00:00:40.720 --> 00:00:45.190
So for example, if you've heard
of the Bitcoin, the Bitcoin

00:00:45.190 --> 00:00:48.160
electronic payment system,
that system actually

00:00:48.160 --> 00:00:52.130
leverages a proof of work
scheme within the context

00:00:52.130 --> 00:00:57.860
of creating what are known
as transaction block chains.

00:00:57.860 --> 00:01:01.300
Now aside from Bitcoin,
which is a very recent user

00:01:01.300 --> 00:01:04.607
of these types of
proof of work schemes,

00:01:04.607 --> 00:01:06.440
these schemes have been
proposed in the past

00:01:06.440 --> 00:01:07.550
for other applications.

00:01:07.550 --> 00:01:09.712
For example, proof
of work schemes

00:01:09.712 --> 00:01:11.170
have been proposed
for doing things

00:01:11.170 --> 00:01:14.760
like deterring denial-of-service
attacks, or DoS attacks.

00:01:14.760 --> 00:01:17.720
And here the idea is
that the requester

00:01:17.720 --> 00:01:19.630
of a particular
service would have

00:01:19.630 --> 00:01:24.140
to solve a very specific
computational problem, a proof

00:01:24.140 --> 00:01:27.670
of work puzzle, before being
allowed to use a service.

00:01:27.670 --> 00:01:31.000
And the idea here is that the
computational effort exerted

00:01:31.000 --> 00:01:34.680
is effectively a way to
throttle the requester.

00:01:34.680 --> 00:01:36.180
The responder can,
in turn, easily

00:01:36.180 --> 00:01:39.520
check if the requester carried
out the requisite work,

00:01:39.520 --> 00:01:42.200
and only if that work was
carried out will the responder

00:01:42.200 --> 00:01:45.810
respond to that
request for service.

00:01:45.810 --> 00:01:48.859
Now the original
application for these types

00:01:48.859 --> 00:01:50.650
of proof of work
protocols, the first place

00:01:50.650 --> 00:01:53.360
that I've seen it
proposed, is in the context

00:01:53.360 --> 00:01:56.100
of being able to
deter spam email.

00:01:56.100 --> 00:01:58.676
And then obviously, we all know
what spam email is hopefully.

00:01:58.676 --> 00:02:01.050
These are messages that you
don't want in your inbox that

00:02:01.050 --> 00:02:04.780
maybe come to you in
an unsolicited fashion.

00:02:04.780 --> 00:02:08.419
And the idea here is that
a proof of work protocol,

00:02:08.419 --> 00:02:11.720
it turns out it can be tied
to a particular email message.

00:02:11.720 --> 00:02:14.910
And this is conceptually
like affixing a postage stamp

00:02:14.910 --> 00:02:20.200
to a message, but rather than
paying for that stamp using

00:02:20.200 --> 00:02:24.690
money, you're basically paying
for that stamp via CPU cycles.

00:02:24.690 --> 00:02:27.400
So for a legitimate sender
who is only sending out

00:02:27.400 --> 00:02:31.420
a small number of messages, this
type of proof of work protocol

00:02:31.420 --> 00:02:32.860
will not amount to very much.

00:02:32.860 --> 00:02:35.670
It's going to be a minor
deterrent since it's only

00:02:35.670 --> 00:02:38.250
executed a very small
number of times.

00:02:38.250 --> 00:02:40.060
It's kind of an
impediment, but it's not

00:02:40.060 --> 00:02:42.970
something that's
so unreasonable.

00:02:42.970 --> 00:02:46.090
Now for a spammer, who might be
sending out a lot of messages,

00:02:46.090 --> 00:02:49.050
maybe hundreds of thousands,
or millions of messages,

00:02:49.050 --> 00:02:52.680
it might be prohibitively
expensive to repeatedly expend

00:02:52.680 --> 00:02:55.880
so many CPU cycles for each
message and each sender

00:02:55.880 --> 00:02:58.540
to whom that message
is being sent.

00:02:58.540 --> 00:03:00.040
So hopefully this
gives you a flavor

00:03:00.040 --> 00:03:03.180
for some of the applications of
these proof of work protocols.

00:03:03.180 --> 00:03:07.296
Let me actually dive in to
how they work in practice.

00:03:07.296 --> 00:03:08.796
So first of all,
the way that I like

00:03:08.796 --> 00:03:11.590
to think of these protocols
is that typically, they

00:03:11.590 --> 00:03:14.900
work relative to a
given challenge string.

00:03:14.900 --> 00:03:16.750
And I'm going to
call this challenge

00:03:16.750 --> 00:03:20.120
string-- we'll label
it with the letter c.

00:03:20.120 --> 00:03:22.700
So c's going to be kind
of a challenge string.

00:03:22.700 --> 00:03:27.210
And what the person trying to
engage in the protocol will do,

00:03:27.210 --> 00:03:30.870
the prover of the
work, will basically

00:03:30.870 --> 00:03:34.630
try to come up with a
corresponding proof that

00:03:34.630 --> 00:03:36.680
is tied to this
challenge string.

00:03:36.680 --> 00:03:38.967
It's going to be kind
of a response associated

00:03:38.967 --> 00:03:39.800
with this challenge.

00:03:39.800 --> 00:03:42.880
It has a very specific
mathematical property

00:03:42.880 --> 00:03:44.954
in relation to this challenge.

00:03:44.954 --> 00:03:47.620
And as you point out, maybe when
I talk about a challenge string

00:03:47.620 --> 00:03:49.530
here, for example in
the context of spam,

00:03:49.530 --> 00:03:51.030
this challenge
string might actually

00:03:51.030 --> 00:03:52.984
represent an email message.

00:03:52.984 --> 00:03:54.400
So it's going to
be something very

00:03:54.400 --> 00:03:57.810
specific to the task at hand.

00:03:57.810 --> 00:04:00.710
Now what the prover will do is
come up with a response string,

00:04:00.710 --> 00:04:07.340
and let's call the
response string r.

00:04:07.340 --> 00:04:09.470
Actually, let's use
the term p for it,

00:04:09.470 --> 00:04:13.650
since maybe we can think
of it as a proof, a proof

00:04:13.650 --> 00:04:16.170
or a response.

00:04:16.170 --> 00:04:19.459
And the idea is that the prover
will come up with this proof

00:04:19.459 --> 00:04:23.170
or response string, and he has
to come up with a string such

00:04:23.170 --> 00:04:25.670
that, when you concatenate the
challenge and the response,

00:04:25.670 --> 00:04:29.396
and you take the two
together, and you apply

00:04:29.396 --> 00:04:31.062
a cryptographic hash
function-- so let's

00:04:31.062 --> 00:04:32.687
say I come up with
a cryptographic hash

00:04:32.687 --> 00:04:37.240
function, like SHA-256, or
anything of that nature.

00:04:37.240 --> 00:04:40.290
If I take the challenge
string and the proof string

00:04:40.290 --> 00:04:42.720
and concatenate together and
apply the cryptographic hash

00:04:42.720 --> 00:04:45.710
function, apply these
mathematical transformations

00:04:45.710 --> 00:04:48.170
that represent the
cryptographic hash function,

00:04:48.170 --> 00:04:49.920
I want to come up with
a proof string such

00:04:49.920 --> 00:04:53.030
that the output under
this hash function

00:04:53.030 --> 00:04:55.550
will have a very
specific property.

00:04:55.550 --> 00:05:00.070
The prefix of the output, the
first large number of bits

00:05:00.070 --> 00:05:01.040
will all be 0.

00:05:01.040 --> 00:05:05.746
So let's say the first 40
bits, or first 30 bits,

00:05:05.746 --> 00:05:07.120
or some number of
bits will be 0.

00:05:09.690 --> 00:05:12.550
And then the other bits can be
whatever they would normally

00:05:12.550 --> 00:05:13.709
be.

00:05:13.709 --> 00:05:15.500
So obviously, what
you're trying to do here

00:05:15.500 --> 00:05:17.676
is come up with a
proof string that

00:05:17.676 --> 00:05:19.550
has a relationship with
the challenge string.

00:05:19.550 --> 00:05:21.008
And that relationship
happens to be

00:05:21.008 --> 00:05:26.515
one that is taken with respect
to a particular hash function,

00:05:26.515 --> 00:05:30.220
and really incorporates
or considers

00:05:30.220 --> 00:05:32.210
what the output of
the hash function

00:05:32.210 --> 00:05:35.960
will be when the proof string is
concatenated with the challenge

00:05:35.960 --> 00:05:37.760
string.

00:05:37.760 --> 00:05:40.130
And if you, let's say, have
a good cryptographic hash

00:05:40.130 --> 00:05:42.960
function, then
the only known way

00:05:42.960 --> 00:05:44.885
to find this type
of a proof string

00:05:44.885 --> 00:05:49.130
is to effectively try a lot
of different possibilities,

00:05:49.130 --> 00:05:51.040
effectively doing
brute force, by trying

00:05:51.040 --> 00:05:54.005
a lot of different proof strings
until you find one that works.

00:05:54.005 --> 00:05:56.040
Now if you, let's
say, needed to find

00:05:56.040 --> 00:06:00.950
an output that contained about
40 consecutive 0's in it, that

00:06:00.950 --> 00:06:03.850
would require you to
perform about 2 to the power

00:06:03.850 --> 00:06:08.780
40 steps, 2 to the power
40 different hash function

00:06:08.780 --> 00:06:09.380
indications.

00:06:09.380 --> 00:06:12.820
You'd have to try 2 to the
40 different strings, and one

00:06:12.820 --> 00:06:15.490
of them what would likely
work if you tried 2

00:06:15.490 --> 00:06:16.460
to the 40 such strings.

00:06:16.460 --> 00:06:19.340
That actually requires you to
try about, and 2 to the 40 just

00:06:19.340 --> 00:06:22.900
to give you a sense, is
approximately 1 trillion.

00:06:22.900 --> 00:06:25.440
So if you tried a trillion
different strings out,

00:06:25.440 --> 00:06:28.670
and you hashed them
each, you would likely

00:06:28.670 --> 00:06:33.070
come up with one string that
had the first 40 bits being 0.

00:06:33.070 --> 00:06:34.820
Now sometimes it might
take you a lot less

00:06:34.820 --> 00:06:35.790
than a trillion steps.

00:06:35.790 --> 00:06:38.480
Sometimes it might take
you a little bit more.

00:06:38.480 --> 00:06:39.510
You may get very lucky.

00:06:39.510 --> 00:06:41.320
You might get very unlucky.

00:06:41.320 --> 00:06:45.090
But on average, it will take
you about 1 trillion steps

00:06:45.090 --> 00:06:51.890
to find a string where the
first 40 bits are equal to 0.

00:06:51.890 --> 00:06:54.510
So this is something
that's not easy,

00:06:54.510 --> 00:06:57.495
but it's also not outside
the realm of possibility.

00:06:57.495 --> 00:06:59.430
Now to understand
why it's really hard

00:06:59.430 --> 00:07:02.350
to solve these types of
proof of work schemes more

00:07:02.350 --> 00:07:04.560
efficiently than maybe
simply doing brute force,

00:07:04.560 --> 00:07:07.070
I think it's helpful to
recall that the output

00:07:07.070 --> 00:07:10.895
of a cryptographic hash function
looks more or less random.

00:07:10.895 --> 00:07:16.190
In fact, each output bit looks
like a series of coin flips.

00:07:16.190 --> 00:07:17.815
So it's kind of like
flipping the coin,

00:07:17.815 --> 00:07:19.890
and if it comes up heads,
you would have a 0,

00:07:19.890 --> 00:07:22.230
and if it comes up tails,
you can think of it as a 1.

00:07:22.230 --> 00:07:23.646
And so what you're
really doing is

00:07:23.646 --> 00:07:27.500
saying, if I flipped 40 coins,
what are the odds that you

00:07:27.500 --> 00:07:32.120
would have 40 consecutive
heads on those 40 coin flips?

00:07:32.120 --> 00:07:35.460
Now obviously that
likelihood is very small,

00:07:35.460 --> 00:07:37.750
but it's not outside the
realm of possibility.

00:07:37.750 --> 00:07:42.280
If you flipped 40 coins and
you flipped those 40 coins

00:07:42.280 --> 00:07:45.100
about a trillion times,
you would actually

00:07:45.100 --> 00:07:49.170
expect to see one instance
in which all 40 coins came up

00:07:49.170 --> 00:07:53.372
as heads out of
a trillion tries.

00:07:53.372 --> 00:07:55.830
Now one interesting thing with
these proof of work schemes,

00:07:55.830 --> 00:07:57.870
is they can be ratcheted
up or ratcheted down.

00:07:57.870 --> 00:08:00.050
So for example,
let's say you want

00:08:00.050 --> 00:08:02.690
to require even more
computational heavy lifting

00:08:02.690 --> 00:08:05.170
to come up with a
correct proof string.

00:08:05.170 --> 00:08:09.270
Let's say you want to
increase the work that's

00:08:09.270 --> 00:08:10.270
going to be proved here.

00:08:10.270 --> 00:08:12.020
What you can effectively
do, in that case,

00:08:12.020 --> 00:08:14.440
is you could just increase
the requirement on a number

00:08:14.440 --> 00:08:15.727
of leading 0's.

00:08:15.727 --> 00:08:17.310
So every time you
add an additional 0,

00:08:17.310 --> 00:08:20.930
you effectively double the
computational horsepower

00:08:20.930 --> 00:08:22.144
needed on average.

00:08:22.144 --> 00:08:23.560
And that's because
you effectively

00:08:23.560 --> 00:08:26.830
requiring one more coin
flip to come up heads,

00:08:26.830 --> 00:08:30.120
and that entails doubling
the number of coin flips.

00:08:30.120 --> 00:08:34.429
So if I had 41 coin flips and
I required 41 straight heads,

00:08:34.429 --> 00:08:36.470
that would require about
twice as much effort

00:08:36.470 --> 00:08:39.640
as just requiring
40 straight heads.

00:08:39.640 --> 00:08:42.570
And likewise, every time you
remove a 0 from consideration,

00:08:42.570 --> 00:08:44.580
or the requirement,
that will reduce

00:08:44.580 --> 00:08:47.190
the computational horsepower
needed to about half

00:08:47.190 --> 00:08:48.360
of what it was previously.

00:08:48.360 --> 00:08:52.190
So for example, if I only
required the first 39 bits

00:08:52.190 --> 00:08:56.380
to be 0, that would require
about half as many coin flips

00:08:56.380 --> 00:08:59.950
as requiring the
first 40 bits to be 0.

00:08:59.950 --> 00:09:03.710
Now the neat thing is that once
you come up with a solution--

00:09:03.710 --> 00:09:06.805
let's say that somebody
tries a trillion times

00:09:06.805 --> 00:09:09.590
and they finally come up
with a proof string that

00:09:09.590 --> 00:09:12.810
works-- it's very easy to
validate that this proof

00:09:12.810 --> 00:09:16.140
string is in fact a
correct proof of work.

00:09:16.140 --> 00:09:18.780
All you have to do is,
you take the challenge

00:09:18.780 --> 00:09:22.050
and you take the proof string
and you hash them together.

00:09:22.050 --> 00:09:25.960
So for example, if somebody
proposes this one string,

00:09:25.960 --> 00:09:29.440
let's call it p prime, all you
do is you take the challenge

00:09:29.440 --> 00:09:31.830
and you take p prime,
and you input them

00:09:31.830 --> 00:09:34.275
into a hash
function, and you see

00:09:34.275 --> 00:09:37.170
if the first 40 bits are all 0.

00:09:37.170 --> 00:09:40.470
So all this requires you to do
is apply a hash function once

00:09:40.470 --> 00:09:43.250
to the concatenation
of c and p prime,

00:09:43.250 --> 00:09:45.570
and you can verify
that the output indeed

00:09:45.570 --> 00:09:48.150
has the requisite number
of 0's in front of it.

00:09:48.150 --> 00:09:51.470
And if you see that the output
has the requisite number

00:09:51.470 --> 00:09:54.727
of 0's, then you can consider
the proof of work valid,

00:09:54.727 --> 00:09:56.810
because you know it must
have taken somebody a lot

00:09:56.810 --> 00:10:01.110
of time, a lot of tries
really, to provide or come up

00:10:01.110 --> 00:10:04.310
with the string p prime, such
that the concatenation of c

00:10:04.310 --> 00:10:08.800
and p prime gives
you a number of 0's

00:10:08.800 --> 00:10:11.490
under the application of this
cryptographic hash function.

00:10:11.490 --> 00:10:14.610
So as you can see, these
schemes are quite simple,

00:10:14.610 --> 00:10:16.600
but quite clever
at the same time.

00:10:16.600 --> 00:10:18.990
They really amount to coming
up with a proof string that

00:10:18.990 --> 00:10:22.530
has a very specific,
mathematical relationship

00:10:22.530 --> 00:10:24.060
with the original
challenge string.

00:10:24.060 --> 00:10:25.768
So hopefully this
video gave you a flavor

00:10:25.768 --> 00:10:32.020
for the mechanics of how these
proof of work protocols work.


Bitcoin - Transaction records

WEBVTT
Kind: captions
Language: en

00:00:00.532 --> 00:00:02.524
Voiceover: At its core,
bitcoin is just basically

00:00:02.524 --> 00:00:05.440
a chain of digital signatures
that really reflect

00:00:05.440 --> 00:00:09.526
the coin's path through
the bitcoin ecosystem.

00:00:09.526 --> 00:00:10.772
And, you know what? I think it's actually

00:00:10.772 --> 00:00:13.572
conceptually easier to think of bitcoins

00:00:13.572 --> 00:00:17.360
as collective entries into a ledger

00:00:17.360 --> 00:00:19.420
rather than as a physical coin

00:00:19.420 --> 00:00:21.696
because if you think
about it, in a ledger,

00:00:21.696 --> 00:00:23.958
you have a record of
transaction histories,

00:00:23.958 --> 00:00:25.858
which is what happens in bitcoin,

00:00:25.858 --> 00:00:28.630
whereas with the physical coin,

00:00:28.630 --> 00:00:30.162
it's more, like, memory-less.

00:00:30.162 --> 00:00:31.757
There's no history in a physical coin

00:00:31.757 --> 00:00:34.630
of where that coin has
really been in the past.

00:00:34.630 --> 00:00:37.360
In this context, you can
think of a transaction

00:00:37.360 --> 00:00:42.136
as just a digitally-signed
declaration by one party

00:00:42.136 --> 00:00:45.136
of its intent to transfer some bitcoins

00:00:45.136 --> 00:00:47.902
that they possess to
another set of parties.

00:00:47.902 --> 00:00:49.472
And when I say one party possesses

00:00:49.472 --> 00:00:50.469
a certain number of bitcoins,

00:00:50.469 --> 00:00:52.201
I really just mean here that

00:00:52.201 --> 00:00:54.564
there are some previous
transactions on record

00:00:54.564 --> 00:00:55.859
that everybody's agreed to

00:00:55.859 --> 00:00:58.759
in which the party now
transferring the bitcoins

00:00:58.759 --> 00:01:02.857
was itself the recipient
of a previous transfer

00:01:02.857 --> 00:01:05.292
of those bitcoins, all right?

00:01:05.292 --> 00:01:06.966
Now, I realize it's a bit convoluted,

00:01:06.966 --> 00:01:10.170
so maybe to help better
understand the mechanics

00:01:10.170 --> 00:01:10.964
of a transaction,

00:01:10.964 --> 00:01:12.992
I can do an example of what would happen

00:01:12.992 --> 00:01:16.802
in the context of an
actual bitcoin transaction.

00:01:16.802 --> 00:01:17.791
Let's say we have a party,

00:01:17.791 --> 00:01:19.398
and let's call her Alice,

00:01:19.398 --> 00:01:22.462
which is the common
name we use for parties

00:01:22.462 --> 00:01:24.188
in cryptographic schemes,

00:01:24.188 --> 00:01:26.314
and let's say she wants to transfer

00:01:26.314 --> 00:01:27.607
some bitcoins to Bob,

00:01:27.607 --> 00:01:30.089
and let's say she would like,

00:01:30.089 --> 00:01:32.540
has an intention of wanting to transfer

00:01:32.540 --> 00:01:37.272
50 bitcoins to Bob.

00:01:37.766 --> 00:01:40.635
Now, remember that anybody who transacts

00:01:40.635 --> 00:01:43.959
in the bitcoin ecosystem
is actually not transacting

00:01:43.959 --> 00:01:46.771
under their real name,
or their actual name,

00:01:46.771 --> 00:01:50.542
but rather they are known
by a very specific identity,

00:01:50.542 --> 00:01:53.207
a pseudonym within the bitcoin ecosystem,

00:01:53.207 --> 00:01:55.384
and that identity, that
pseudonym is actually

00:01:55.384 --> 00:01:58.381
that actually corresponds
to a public verification key

00:01:58.381 --> 00:01:59.635
for a digital signature scheme.

00:01:59.635 --> 00:02:02.217
So, in this case, let's
say Alice's identity

00:02:02.217 --> 00:02:05.381
in the system is really some
public verification key,

00:02:05.381 --> 00:02:08.493
which we'll call VK of A,

00:02:08.493 --> 00:02:10.502
so Alice's verification key,

00:02:10.502 --> 00:02:12.068
and in the context of Bob,

00:02:12.068 --> 00:02:17.136
let's say his public
verification key is VK sub B.

00:02:17.136 --> 00:02:18.659
So, these are keys that are used

00:02:18.659 --> 00:02:20.770
within digital signature schemes,

00:02:20.770 --> 00:02:22.331
and so we can assume
that Alice has generated

00:02:22.331 --> 00:02:25.052
this key at some point, and
that she made it public,

00:02:25.052 --> 00:02:26.582
and that Bob did the same thing,

00:02:26.582 --> 00:02:28.385
and so now they both have identities

00:02:28.385 --> 00:02:28.964
within the system,

00:02:28.964 --> 00:02:31.463
and these identities are
just sequences of numbers

00:02:31.463 --> 00:02:35.557
that correspond to public
keys for verification

00:02:35.557 --> 00:02:38.228
in the context of a
cryptographic digital signature.

00:02:38.228 --> 00:02:39.134
All right?

00:02:39.134 --> 00:02:41.216
Now, remember, that these values

00:02:41.216 --> 00:02:43.382
also correspond to private values,

00:02:43.382 --> 00:02:45.380
so each person who's got a public key

00:02:45.380 --> 00:02:47.938
will have a corresponding private key,

00:02:47.938 --> 00:02:49.457
associated with that public key,

00:02:49.457 --> 00:02:51.719
and in this case, we'll
call the private key,

00:02:51.719 --> 00:02:53.463
or the secret key, which is, in fact,

00:02:53.463 --> 00:02:56.503
a signing key in this
context, SK of Alice,

00:02:56.503 --> 00:03:01.890
and we'll say that Bob's
signing key is SK of Bob.

00:03:01.890 --> 00:03:02.837
Okay?

00:03:02.837 --> 00:03:03.688
And they're going to basically

00:03:03.688 --> 00:03:05.206
keep these keys private.

00:03:05.206 --> 00:03:07.640
Now let's say that Alice
herself had received

00:03:07.640 --> 00:03:08.440
in the past,

00:03:08.440 --> 00:03:10.992
three transactions of
bitcoins from other parties.

00:03:10.992 --> 00:03:15.876
Let's say she got 25 bitcoins from Carol,

00:03:15.876 --> 00:03:18.993
and we'll call Carol VK
of C to associate that

00:03:18.993 --> 00:03:19.677
with her key,

00:03:19.677 --> 00:03:23.731
let's say she got 20 public,

00:03:23.731 --> 00:03:28.204
or 20 bitcoins, rather, from David,

00:03:28.204 --> 00:03:33.333
and let's say she got 20
more bitcoins from Ted.

00:03:33.333 --> 00:03:33.714
Okay?

00:03:33.714 --> 00:03:35.033
So these are,

00:03:35.033 --> 00:03:37.393
these bitcoins correspond
to different people

00:03:37.393 --> 00:03:40.046
that provided Alice with
bitcoins in the past,

00:03:40.046 --> 00:03:40.938
and so as you can see,

00:03:40.938 --> 00:03:43.117
Alice now has an aggregate of 65,

00:03:43.117 --> 00:03:46.492
which is 20 plus 20 plus 25 bitcoins,

00:03:46.492 --> 00:03:47.737
and so as a result,

00:03:47.737 --> 00:03:50.744
she has a sufficient number to be able to

00:03:50.744 --> 00:03:53.999
transfer 50 of those
bitcoins to Bob, okay?

00:03:53.999 --> 00:03:56.508
So to start off with, a
transaction from Alice to Bob

00:03:56.508 --> 00:03:59.714
for 50 bitcoins will
contain information about

00:03:59.714 --> 00:04:00.807
these previous transactions,

00:04:00.807 --> 00:04:02.845
so each of these previous transactions

00:04:02.845 --> 00:04:05.796
where Alice received some bitcoins,

00:04:05.796 --> 00:04:07.025
these will have been recorded

00:04:07.025 --> 00:04:08.320
in the bitcoin ecosystem,

00:04:08.320 --> 00:04:09.666
so they're going to be made public,

00:04:09.666 --> 00:04:11.367
just like every other transaction,

00:04:11.367 --> 00:04:12.715
and so what Alice can actually do

00:04:12.715 --> 00:04:14.983
is she can take some representation

00:04:14.983 --> 00:04:17.149
of these transactions and include them

00:04:17.149 --> 00:04:19.652
as part of the new transaction with Bob,

00:04:19.652 --> 00:04:21.799
basically as an anchor point to say,

00:04:21.799 --> 00:04:23.917
"Hey, I received these previous bitcoins,

00:04:23.917 --> 00:04:24.595
"and now I'm going to transfer

00:04:24.595 --> 00:04:27.941
"some portion of these
bitcoins to you, Bob."

00:04:27.941 --> 00:04:28.945
Okay?

00:04:28.945 --> 00:04:30.996
So, in this context, actually,

00:04:30.996 --> 00:04:33.536
she does not need to include the full

00:04:33.536 --> 00:04:36.719
transaction details in the
actual transaction record

00:04:36.719 --> 00:04:37.649
to Bob.

00:04:37.649 --> 00:04:38.795
What she can instead do

00:04:38.795 --> 00:04:41.054
is take the transaction details and apply

00:04:41.054 --> 00:04:44.722
a cryptographic hash function to them

00:04:44.722 --> 00:04:47.696
to get a series of digests
for each transaction.

00:04:47.696 --> 00:04:50.202
So in this case, let's
say she has a digest

00:04:50.202 --> 00:04:52.502
that corresponds to the
transaction of Carol,

00:04:52.502 --> 00:04:53.991
she'll have a digest that corresponds

00:04:53.991 --> 00:04:56.645
to the transaction from David,

00:04:56.645 --> 00:04:58.607
and she'll have a digest that corresponds

00:04:58.607 --> 00:05:00.480
to the transaction from Ted, okay?

00:05:00.480 --> 00:05:03.566
And she'll basically include
each of these digests

00:05:03.566 --> 00:05:06.505
into the transaction record,

00:05:06.505 --> 00:05:08.434
and what these [trackers] allow you to do,

00:05:08.434 --> 00:05:10.387
or really allow anyone
to do, for that matter,

00:05:10.387 --> 00:05:12.842
is they can verify the chain of ownership

00:05:12.842 --> 00:05:14.066
of these bitcoins,

00:05:14.066 --> 00:05:15.652
because they can simply take

00:05:15.652 --> 00:05:17.152
all the previous transaction records,

00:05:17.152 --> 00:05:18.800
which, again, are made public.

00:05:18.800 --> 00:05:20.730
They can apply
cryptographic hash functions

00:05:20.730 --> 00:05:23.814
to these different transaction records,

00:05:23.814 --> 00:05:26.096
and they can verify that
these cryptographic hashes,

00:05:26.096 --> 00:05:27.963
when applied to those transaction records

00:05:27.963 --> 00:05:30.806
provide you back with the
values D sub C, D sub D,

00:05:30.806 --> 00:05:31.768
and D sub T,

00:05:31.768 --> 00:05:33.210
and that, in turn, provides you with

00:05:33.210 --> 00:05:35.794
some type of a cryptographic guarantee

00:05:35.794 --> 00:05:37.192
because we're using
cryptographic hash functions,

00:05:37.192 --> 00:05:39.070
we have a cryptographic guarantee that,

00:05:39.070 --> 00:05:41.719
that Alice was the ultimate recipient of

00:05:41.719 --> 00:05:43.437
these transactions from
these different parties.

00:05:43.437 --> 00:05:46.144
We have this nice history
that we can record,

00:05:46.144 --> 00:05:49.109
and that we can essentially
ascertain in this fashion.

00:05:49.109 --> 00:05:49.850
All right?

00:05:49.850 --> 00:05:51.680
Because we're using
cryptographic hash functions,

00:05:51.680 --> 00:05:53.900
we now have some assurance that Alice

00:05:53.900 --> 00:05:55.826
couldn't have so easily
cheated the system,

00:05:55.826 --> 00:05:56.726
all right?

00:05:56.726 --> 00:05:58.498
So, at this point in the transaction,

00:05:58.498 --> 00:06:00.646
and maybe I'll kind of draw a line

00:06:00.646 --> 00:06:01.691
so you can kind of see

00:06:01.691 --> 00:06:04.029
where the transaction
details are recorded.

00:06:04.029 --> 00:06:05.384
So at this point of the transaction,

00:06:05.384 --> 00:06:07.669
we have details about Alice's ownership

00:06:07.669 --> 00:06:09.809
of these 65 bitcoins,

00:06:09.809 --> 00:06:11.778
and she has enough information
in that transaction

00:06:11.778 --> 00:06:13.661
so that anybody can verify

00:06:13.661 --> 00:06:15.825
that she possessed these coins.

00:06:15.825 --> 00:06:18.346
You can think of this part
of the transaction, really,

00:06:18.346 --> 00:06:20.829
as representing the input,

00:06:20.829 --> 00:06:22.538
the input to the transaction.

00:06:22.538 --> 00:06:24.054
Now, in addition to the input portion

00:06:24.054 --> 00:06:24.696
of the transaction,

00:06:24.696 --> 00:06:27.190
there's typically also an output portion.

00:06:27.190 --> 00:06:29.246
I'm going to put that
output portion up here,

00:06:29.246 --> 00:06:31.071
but let me label it,

00:06:31.071 --> 00:06:32.674
and so for starters,
in the output portion,

00:06:32.674 --> 00:06:33.869
she has to include,

00:06:33.869 --> 00:06:36.204
or Alice has to include
a list of recipients

00:06:36.204 --> 00:06:37.376
for her bitcoins,

00:06:37.376 --> 00:06:38.623
and since Alice wants to,

00:06:38.623 --> 00:06:40.694
let's say, transfer these bitcoins to Bob,

00:06:40.694 --> 00:06:43.828
she has to specify Bob's
identity in the system,

00:06:43.828 --> 00:06:45.304
which, in fact, as you mentioned earlier

00:06:45.304 --> 00:06:47.091
was Bob's public key,

00:06:47.091 --> 00:06:52.687
so we'll say that she'll
mention V sub K of B,

00:06:52.687 --> 00:06:55.770
and she also has to record
and mention at this stage

00:06:55.770 --> 00:06:57.922
how many coins she
wants to transfer to Bob

00:06:57.922 --> 00:06:59.711
and as we said earlier,
we were going to assume

00:06:59.711 --> 00:07:02.584
that Alice wanted to transfer exactly 50

00:07:02.584 --> 00:07:05.369
of her bitcoins to Bob, okay?

00:07:05.369 --> 00:07:06.607
So she's going to
specify the number of 50.

00:07:06.607 --> 00:07:09.002
Actually, in reality, she'll
specify another number,

00:07:09.002 --> 00:07:13.189
but it's going to represent
50 bitcoins for Bob, okay?

00:07:13.189 --> 00:07:15.593
Now, in order for Alice to get back change

00:07:15.593 --> 00:07:18.133
because she has 65
bitcoins kind of coming in,

00:07:18.133 --> 00:07:20.734
and she is only giving 50 back to Bob,

00:07:20.734 --> 00:07:22.031
what she might then do is decide that

00:07:22.031 --> 00:07:24.997
she's going to specify
14 of those bitcoins

00:07:24.997 --> 00:07:26.850
to be returned back to her

00:07:26.850 --> 00:07:29.307
in the form of change,

00:07:29.307 --> 00:07:33.091
so 14 of those bitcoins
are going to be reassigned

00:07:33.091 --> 00:07:36.687
back to Alice's public key, all right?

00:07:36.687 --> 00:07:38.661
And what Alice will then
do is she's going to take

00:07:38.661 --> 00:07:41.178
all of this data, this transaction data,

00:07:41.178 --> 00:07:42.800
this input and this output,

00:07:42.800 --> 00:07:45.189
and she's going to
digitally sign that data,

00:07:45.189 --> 00:07:48.109
and she's going to use her signing key,

00:07:48.109 --> 00:07:49.661
her signing key,

00:07:49.661 --> 00:07:51.193
to digitally sign all this data,

00:07:51.193 --> 00:07:53.060
like you would with a digital signature,

00:07:53.060 --> 00:07:56.120
and she's going to append that signature

00:07:56.750 --> 00:08:01.025
to the actual contents of
the transaction record,

00:08:01.025 --> 00:08:04.127
and that'll effectively
bind Alice's identity

00:08:04.480 --> 00:08:06.711
with the transaction record itself.

00:08:06.711 --> 00:08:07.862
And the reason it's going to bind it is

00:08:07.862 --> 00:08:09.749
we're using a digital signature scheme,

00:08:09.749 --> 00:08:13.317
and so anybody who possesses
Alice's public key,

00:08:13.317 --> 00:08:14.554
which, again, is made public,

00:08:14.554 --> 00:08:17.859
can validate that only
Alice could have created

00:08:17.859 --> 00:08:19.752
this block because only Alice, in theory,

00:08:19.752 --> 00:08:21.614
can come up with the signature

00:08:21.614 --> 00:08:23.025
that corresponds to her public key

00:08:23.025 --> 00:08:24.867
because she's the only
person who, in theory,

00:08:24.867 --> 00:08:27.712
should possess the private signing key

00:08:27.712 --> 00:08:30.565
corresponding to her
public key, all right?

00:08:30.565 --> 00:08:34.136
Then all of this data will
actually be broadcast out,

00:08:34.136 --> 00:08:36.809
so this transaction data
will then get broadcast out

00:08:36.809 --> 00:08:39.346
to all the different peers and the nodes

00:08:39.346 --> 00:08:41.368
in the bitcoin network.

00:08:41.368 --> 00:08:42.849
Everybody in the bitcoin network

00:08:42.849 --> 00:08:45.679
will basically know now that

00:08:45.956 --> 00:08:51.136
VK sub A is trying to send
50 bitcoins to VK sub B.

00:08:51.136 --> 00:08:51.735
Now, at this point,

00:08:51.735 --> 00:08:54.146
you may have noticed a
slight discrepancy here

00:08:54.146 --> 00:08:57.664
that Alice started off with 65 coins,

00:08:57.664 --> 00:08:59.204
kind of on the input side,

00:08:59.204 --> 00:09:01.888
but on the output side,
she only has 50 plus 14,

00:09:01.888 --> 00:09:05.277
or 64 coins that are being accounted for.

00:09:05.277 --> 00:09:07.599
So there's this issue,
what happens with this one,

00:09:07.599 --> 00:09:09.470
one last remaining coin?

00:09:09.470 --> 00:09:11.701
There's kind of this one
implicit coin hanging around

00:09:11.701 --> 00:09:13.351
that has not been accounted for,

00:09:13.351 --> 00:09:16.100
and what we're going to do with that coin

00:09:16.100 --> 00:09:17.689
is that coin is actually going to be used

00:09:17.689 --> 00:09:18.905
as a transaction fee.

00:09:18.905 --> 00:09:22.970
Alice is basically saying
that this one leftover coin

00:09:22.970 --> 00:09:25.741
should be provided as transaction fee

00:09:25.741 --> 00:09:30.676
to what's known as a bitcoin miner.

00:09:30.676 --> 00:09:33.170
A bitcoin miner, as I
mentioned in a previous video,

00:09:33.170 --> 00:09:35.787
is basically an entity
in the bitcoin system.

00:09:35.787 --> 00:09:37.938
Anybody can be a bitcoin miner, actually,

00:09:37.938 --> 00:09:39.573
but it's a node in the bitcoin network

00:09:39.573 --> 00:09:41.583
who engages, really, in the effort

00:09:41.583 --> 00:09:46.105
to help with the broader
validation of this transaction.

00:09:46.105 --> 00:09:48.170
So what do I mean by broader validation?

00:09:48.170 --> 00:09:49.392
Well, if you think about it,

00:09:49.392 --> 00:09:51.112
at this point, we've just used

00:09:51.112 --> 00:09:54.039
cryptographic hashing and
digital signing to validate

00:09:54.039 --> 00:09:56.422
that Alice at some point possessed

00:09:56.422 --> 00:09:58.696
the requisite bitcoins in the system,

00:09:58.696 --> 00:10:01.005
and that she not only publically announced

00:10:01.005 --> 00:10:03.619
her intention to transfer
some of the bitcoins to Bob,

00:10:03.619 --> 00:10:06.381
but she digitally signed
that public pronouncement,

00:10:06.381 --> 00:10:08.220
if you will, as a result of which,

00:10:08.220 --> 00:10:09.719
her public verification key,

00:10:09.719 --> 00:10:11.610
which is her identity
in the bitcoin system,

00:10:11.610 --> 00:10:13.705
is now bound to that transaction.

00:10:13.705 --> 00:10:15.506
But, what Bob doesn't know yet,

00:10:15.506 --> 00:10:16.838
even though he knows all of these things

00:10:16.838 --> 00:10:17.748
and he can validate them,

00:10:17.748 --> 00:10:18.971
what Bob doesn't know yet

00:10:18.971 --> 00:10:21.909
is whether Alice tried to,
let's say, previously sign,

00:10:21.909 --> 00:10:24.093
or sign those exact same
coins to somebody else.

00:10:24.093 --> 00:10:25.513
Maybe there's another party.

00:10:25.851 --> 00:10:29.060
Let's say Alice has a friend named Eve.

00:10:29.060 --> 00:10:31.512
Maybe Alice decided she's going to send

00:10:31.512 --> 00:10:32.983
these bitcoins not only to Bob,

00:10:32.983 --> 00:10:34.139
but also she's going to try to send

00:10:34.139 --> 00:10:35.901
these same bitcoins to Eve,

00:10:35.901 --> 00:10:38.079
and Bob at this point may
not have the assurance

00:10:38.079 --> 00:10:40.545
that Alice has not tried to engage

00:10:40.545 --> 00:10:43.282
in these types of shenanigans, all right?

00:10:43.282 --> 00:10:44.637
And so the tricky part here is that

00:10:44.637 --> 00:10:47.337
even though all the
transactions we've talked about

00:10:47.337 --> 00:10:49.077
have been made public

00:10:49.077 --> 00:10:50.606
because the bitcoin
requires all transactions

00:10:50.606 --> 00:10:51.634
to be made public,

00:10:51.634 --> 00:10:52.950
we still need a mechanism,

00:10:52.950 --> 00:10:55.133
and this has to be a
decentralized mechanism

00:10:55.133 --> 00:11:00.158
that does not require a
trusted third party, per se.

00:11:00.158 --> 00:11:02.441
We need a decentralized
mechanism for agreeing,

00:11:02.441 --> 00:11:04.749
really, on the order in which transactions

00:11:04.749 --> 00:11:06.149
actually took place,

00:11:06.149 --> 00:11:07.816
so that we can resolve any disputes

00:11:07.816 --> 00:11:12.526
about someone trying to
double spend their coins.

00:11:13.095 --> 00:11:16.221
It's that requirement, that timestamp,

00:11:16.221 --> 00:11:18.297
that decentralized time
stamp, if you will,

00:11:18.297 --> 00:11:20.570
which is where bitcoin miners play

00:11:20.570 --> 00:11:23.378
a very important role in
the bitcoin ecosystem,

00:11:23.378 --> 00:11:25.306
and I'll talk about how that works

00:11:25.306 --> 00:11:28.957
and how we deal with
transaction time stamping

00:11:28.957 --> 23:59:59.999
in subsequent videos.


Bitcoin - Digital Signatures

WEBVTT
Kind: captions
Language: en

00:00:00.499 --> 00:00:02.734
Voiceover: A digital
signature is basically

00:00:02.734 --> 00:00:04.657
the mathematical mechanism

00:00:04.657 --> 00:00:08.329
for essentially combining
a public sequence

00:00:08.329 --> 00:00:10.990
of numbers with a given digital message,

00:00:10.990 --> 00:00:13.825
and you can really think
of a digital signature

00:00:13.825 --> 00:00:16.656
in many ways as the electronic analog

00:00:16.656 --> 00:00:18.651
of a physical signature.

00:00:18.651 --> 00:00:19.987
In a physical signature,

00:00:19.987 --> 00:00:21.546
you'll typically affix, let's say,

00:00:21.546 --> 00:00:23.701
a sequence of characters
representing your name

00:00:23.701 --> 00:00:26.486
or identity to a document.

00:00:26.486 --> 00:00:28.902
This process effectively
binds your identity

00:00:28.902 --> 00:00:30.602
to that document

00:00:30.602 --> 00:00:33.534
and more so by formulating the characters

00:00:33.534 --> 00:00:35.718
in your name, and maybe some

00:00:35.718 --> 00:00:37.663
particular to unique or peculiar way

00:00:37.663 --> 00:00:39.111
that's unique to you.

00:00:39.111 --> 00:00:40.764
The hope is that nobody will be able to

00:00:40.764 --> 00:00:43.398
forge your name on that document.

00:00:43.398 --> 00:00:44.809
Now in a digital signature scheme,

00:00:44.809 --> 00:00:47.949
it turns out you can achieve
these kinds of properties

00:00:47.949 --> 00:00:49.395
mathematically.

00:00:49.395 --> 00:00:50.527
Now, some of the more

00:00:50.527 --> 00:00:51.988
well-known digital signature schemes

00:00:51.988 --> 00:00:55.412
include things like the RSA
digital signature scheme,

00:00:55.412 --> 00:00:58.274
which stands for the
Rivest-Shamir-Adleman scheme.

00:00:58.274 --> 00:01:00.510
There's also a scheme known as DSS,

00:01:00.510 --> 00:01:03.520
which is the digital
signature standard, actually.

00:01:03.520 --> 00:01:05.070
And, actually, if you were to use a scheme

00:01:05.070 --> 00:01:07.630
like RSA or DSS,

00:01:07.630 --> 00:01:10.163
in my mind, it's actually
a lot harder to forge

00:01:10.163 --> 00:01:11.400
these digital signatures

00:01:11.400 --> 00:01:14.369
than it is to forge a
handwritten signature.

00:01:14.369 --> 00:01:15.516
So in this particular video,

00:01:15.516 --> 00:01:19.162
I'll try to describe the
overall higher-level mechanics,

00:01:19.162 --> 00:01:21.841
if you will, of a
digital signature scheme,

00:01:21.841 --> 00:01:24.189
but I won't actually go into or describe

00:01:24.189 --> 00:01:26.847
the underlying mathematical
details of, let's say,

00:01:26.847 --> 00:01:29.452
a specific scheme like RSA or DSS,

00:01:29.452 --> 00:01:32.500
at least not in this video.

00:01:32.500 --> 00:01:34.627
The way that a digital
signature scheme works

00:01:34.627 --> 00:01:35.870
is let's say you have a user,

00:01:35.870 --> 00:01:37.277
and I'm going to call her Alice,

00:01:37.277 --> 00:01:39.398
and let's say Alice wants to,

00:01:39.398 --> 00:01:41.343
digitally sign a document.

00:01:41.343 --> 00:01:42.533
In the scheme,

00:01:42.533 --> 00:01:43.438
in a digital signature scheme,

00:01:43.438 --> 00:01:46.155
Alice is going to first generate two keys,

00:01:46.155 --> 00:01:51.199
and these two keys are
known as the signing key,

00:01:51.199 --> 00:01:52.398
the signing key,

00:01:52.398 --> 00:01:53.497
which is a private key,

00:01:53.497 --> 00:01:56.437
so I'm going to use red to denote it,

00:01:56.437 --> 00:01:59.125
and we'll abbreviate
the signing key as SK.

00:01:59.125 --> 00:02:00.914
And then Alice is also going to generate

00:02:00.914 --> 00:02:03.914
a separate key known
as a verification key.

00:02:03.914 --> 00:02:05.373
Now the actual process of coming up

00:02:05.373 --> 00:02:07.461
with a signing key and a verification key

00:02:07.461 --> 00:02:09.300
kind of happens concurrently.

00:02:09.300 --> 00:02:11.176
Alice will generate these
two keys at the same time,

00:02:11.176 --> 00:02:11.941
and they're going to have

00:02:11.941 --> 00:02:13.687
a mathematical relationship

00:02:14.209 --> 00:02:15.916
but the interesting thing is

00:02:15.916 --> 00:02:17.364
that you want it to be the case

00:02:17.364 --> 00:02:19.062
that the verification key is public,

00:02:19.062 --> 00:02:21.570
and the signing key will be private

00:02:21.570 --> 00:02:24.373
but more so, in a
digital signature scheme,

00:02:24.373 --> 00:02:28.134
it should be hard to come up
with the verification key,

00:02:28.134 --> 00:02:29.457
or rather, it should be hard to come up

00:02:29.457 --> 00:02:31.044
with the signing key, rather,

00:02:31.044 --> 00:02:34.815
if you only see the verification key.

00:02:35.723 --> 00:02:37.795
Now, let's consider
what a digital signature

00:02:37.795 --> 00:02:38.855
on a message will entail.

00:02:38.855 --> 00:02:40.333
So basically, if you have a message,

00:02:40.333 --> 00:02:43.040
and let's call this message M,

00:02:43.040 --> 00:02:45.880
and you wish to digitally
sign that message.

00:02:45.880 --> 00:02:46.700
What you're going to basically do

00:02:46.700 --> 00:02:49.949
is apply a mathematical transformation,

00:02:49.949 --> 00:02:53.005
Alice is going to apply a
mathematical transformation

00:02:53.005 --> 00:02:57.510
to the message M and her signing key SK,

00:02:57.510 --> 00:03:00.102
and the result of that transformation,

00:03:00.102 --> 00:03:02.422
the output of that
transformation will be a special

00:03:04.128 --> 00:03:06.655
sequence of numbers that
we call the signature.

00:03:06.655 --> 00:03:10.369
The signature on the message M.

00:03:11.046 --> 00:03:12.192
Now, the interesting thing here is that

00:03:12.192 --> 00:03:16.044
the signature basically
is one that is derived

00:03:16.044 --> 00:03:19.646
from a combination of the message M

00:03:19.646 --> 00:03:22.175
together with the signing key,

00:03:22.175 --> 00:03:23.795
the private signing key of Alice,

00:03:23.795 --> 00:03:27.402
and it's going to
effectively produce a short,

00:03:27.402 --> 00:03:31.100
a relatively short sequence
of numbers as an output.

00:03:32.636 --> 00:03:34.596
In particular, digital signature schemes

00:03:34.596 --> 00:03:37.168
should be designed, or
they typically are designed

00:03:37.168 --> 00:03:40.269
so that only the person who possesses

00:03:40.269 --> 00:03:42.990
the signing key, that private signing key

00:03:42.990 --> 00:03:46.002
is capable of generating
this type of an output,

00:03:46.002 --> 00:03:50.116
this type of a signature,
S of M on the message M.

00:03:51.608 --> 00:03:54.885
Now, the verification
process is kind of analogous

00:03:54.885 --> 00:03:56.588
to the signing process,

00:03:56.588 --> 00:03:58.710
but it involves the
public verification key.

00:03:58.710 --> 00:04:00.512
So in the verification process,

00:04:00.512 --> 00:04:02.330
you actually have three different inputs,

00:04:02.330 --> 00:04:03.883
so the first input will be the message

00:04:03.883 --> 00:04:06.972
that you want to verify the signature of.

00:04:06.972 --> 00:04:08.501
You also need in addition to the message,

00:04:08.501 --> 00:04:10.142
you need to get as input

00:04:10.142 --> 00:04:11.844
the signature on that message.

00:04:11.844 --> 00:04:13.953
What does that S of M look like,

00:04:13.953 --> 00:04:17.534
and then finally, the
input, the final input

00:04:17.534 --> 00:04:21.668
to the verification scheme
will be the public key,

00:04:21.668 --> 00:04:26.720
the public verification
key that belongs to Alice.

00:04:26.720 --> 00:04:28.183
These three inputs are put in,

00:04:28.183 --> 00:04:29.779
and there's a mathematical transformation

00:04:29.779 --> 00:04:31.017
that's applied to these inputs,

00:04:31.017 --> 00:04:33.051
and basically what that
mathematical transformation

00:04:33.051 --> 00:04:36.064
is trying to ascertain or to check

00:04:36.064 --> 00:04:39.161
is that the signature that you see

00:04:39.161 --> 00:04:41.333
corresponding with the message M

00:04:41.333 --> 00:04:43.729
is one that would have been produced by

00:04:43.729 --> 00:04:45.948
Alice's private signing key.

00:04:45.948 --> 00:04:47.474
And this private signing key, in turn,

00:04:47.474 --> 00:04:50.553
corresponds to Alice's
public verification key.

00:04:50.553 --> 00:04:53.086
Now, what I think is
really remarkable is that

00:04:53.086 --> 00:04:56.702
you can actually carry out this process

00:04:56.702 --> 00:04:58.534
with just the verification key,

00:04:58.534 --> 00:05:01.165
that you don't actually
need the signing key

00:05:01.165 --> 00:05:02.607
to validate the digital signature.

00:05:02.607 --> 00:05:05.463
You don't even need it
inadvertently or indirectly.

00:05:05.463 --> 00:05:07.059
You can do everything.

00:05:07.059 --> 00:05:08.145
you can verify everything

00:05:08.145 --> 00:05:11.923
with knowledge of only the
public verification key.

00:05:11.923 --> 00:05:13.644
And the verification
procedure basically outputs

00:05:13.644 --> 00:05:15.363
kind of a yes or no.

00:05:15.363 --> 00:05:17.651
It tells you, "Should
I accept the signature,

00:05:17.651 --> 00:05:20.234
"or should I reject it?"

00:05:20.234 --> 00:05:22.536
It's a basic validation procedure.

00:05:22.536 --> 00:05:23.919
And so, as you can see,

00:05:23.919 --> 00:05:28.036
the process of signing
effectively will bind

00:05:28.036 --> 00:05:29.433
this public verification key.

00:05:29.433 --> 00:05:33.143
It binds the public verification
key to Alice, somehow,

00:05:33.143 --> 00:05:35.425
because Alice is the one who published

00:05:35.425 --> 00:05:37.141
this verification key
and told the whole world,

00:05:37.141 --> 00:05:40.017
"Hey, this is my verification
key in the system,

00:05:40.017 --> 00:05:42.962
"and only I will be able to sign messages

00:05:42.962 --> 00:05:45.142
"that will be considered valid

00:05:45.142 --> 00:05:49.162
"with respect to that verification key."

00:05:49.439 --> 00:05:52.975
Because the message is now
being essentially bound

00:05:52.975 --> 00:05:54.585
to this public key,

00:05:54.585 --> 00:05:56.046
and if you think of the public key

00:05:56.046 --> 00:05:57.812
as an identifier of sorts,

00:05:57.812 --> 00:05:59.965
maybe and identifier for Alice,

00:05:59.965 --> 00:06:02.743
then you can think of
digital signing as a process

00:06:02.743 --> 00:06:04.926
that basically binds an identity

00:06:04.926 --> 00:06:06.597
to an underlying message,

00:06:06.597 --> 00:06:09.350
and that really gives us,
in the mathematical sense,

00:06:09.350 --> 00:06:10.838
it gives us the analog

00:06:10.838 --> 00:06:14.104
of a traditional handwritten signature.

00:06:14.104 --> 00:06:15.267
Now, I want to make two remarks,

00:06:15.267 --> 00:06:17.111
and I think they're particularly relevant.

00:06:17.111 --> 00:06:19.187
First of all, you'll notice
that the transformation

00:06:19.187 --> 00:06:24.304
that produces the actual
digital signature itself,

00:06:24.842 --> 00:06:27.672
this transformation right
here that produces S of M,

00:06:27.672 --> 00:06:31.265
this transformation
basically takes the message.

00:06:31.265 --> 00:06:34.417
It takes the message as one of its inputs,

00:06:34.417 --> 00:06:38.362
and what that means is that the signature

00:06:38.362 --> 00:06:39.850
is dependent on the message.

00:06:39.850 --> 00:06:40.857
If you change the message,

00:06:40.857 --> 00:06:42.604
you'll get a different signature.

00:06:42.604 --> 00:06:43.982
Now, in this sense,

00:06:43.982 --> 00:06:46.206
a digital signature is actually different

00:06:46.206 --> 00:06:48.222
from a traditional handwritten signature.

00:06:48.222 --> 00:06:50.537
Your handwritten signature
probably doesn't change.

00:06:50.537 --> 00:06:52.273
It more or less stays the same

00:06:52.273 --> 00:06:54.465
regardless of what it is you're signing.

00:06:54.465 --> 00:06:56.713
But your digital signature
is very sensitive to

00:06:56.713 --> 00:06:57.341
what you're signing,

00:06:57.341 --> 00:06:59.477
and it will vary depending
on what you sign.

00:06:59.477 --> 00:07:00.366
If you sign a different message,

00:07:00.366 --> 00:07:03.376
you'll get a different
signature as an output.

00:07:03.376 --> 00:07:04.694
The second remark I want to make

00:07:04.694 --> 00:07:09.071
is that digital signatures
are often associated with

00:07:09.071 --> 00:07:10.529
a cryptographic hash function,

00:07:10.529 --> 00:07:11.486
and I've already done a video

00:07:11.486 --> 00:07:12.638
on cryptographic hash functions,

00:07:12.638 --> 00:07:14.616
and, in fact, I mention in that video,

00:07:14.616 --> 00:07:16.390
and I'll reiterate here that the first

00:07:16.390 --> 00:07:18.095
cryptographic hash functions
were actually designed

00:07:18.095 --> 00:07:21.905
specifically with digital
signatures in mind

00:07:21.905 --> 00:07:24.815
as their killer application, if you will.

00:07:24.815 --> 00:07:26.665
So, in particular, what
typically happens is that

00:07:26.665 --> 00:07:28.683
before you actually sign
an arbitrary message,

00:07:28.683 --> 00:07:31.133
let's say you have a huge message here

00:07:31.133 --> 00:07:32.713
that you want to sign.

00:07:32.713 --> 00:07:34.094
Before you sign this message,

00:07:34.094 --> 00:07:36.492
you're going to basically apply

00:07:36.492 --> 00:07:39.109
a cryptographic hash
function to that message

00:07:39.109 --> 00:07:41.953
and you're going to get an
output from that function,

00:07:41.953 --> 00:07:43.227
that cryptographic hash function,

00:07:43.227 --> 00:07:44.812
you'll get a shorter output,

00:07:44.812 --> 00:07:47.203
the digest of that
cryptographic hash function,

00:07:47.203 --> 00:07:49.477
and then what you do in a
signing algorithm is that

00:07:49.477 --> 00:07:51.569
rather than signing the original message,

00:07:51.569 --> 00:07:52.636
you will first hash it

00:07:52.636 --> 00:07:54.854
and then sign the hash of the message.

00:07:54.854 --> 00:07:56.299
You'll sign the resulting digest

00:07:56.299 --> 00:07:58.839
instead of the original message.

00:08:01.314 --> 00:08:04.289
This two-step paradigm
of doing kind of hashing

00:08:04.289 --> 00:08:05.518
and then signing,

00:08:05.518 --> 00:08:07.318
really ends up simplifying the process

00:08:07.318 --> 00:08:09.479
of digital signing since you effectively

00:08:09.479 --> 00:08:12.436
are no longer dealing with
an arbitrary length input,

00:08:12.436 --> 00:08:13.715
but instead, you're working with

00:08:13.715 --> 00:08:16.528
a fixed-length quantity.

00:08:16.528 --> 00:08:17.768
And this hashing sign paradigm

00:08:17.768 --> 00:08:21.441
actually is safe as long
as it's hard to find

00:08:21.441 --> 00:08:24.296
two messages that map to the same output

00:08:24.296 --> 00:08:26.068
under the application
of the hash function.

00:08:26.068 --> 00:08:29.152
In other words, you can't
come up with two messages

00:08:29.152 --> 00:08:30.683
that are different,

00:08:30.683 --> 00:08:32.890
but whose output when the hash function is

00:08:32.890 --> 00:08:34.869
applied to them are identical.

00:08:34.869 --> 00:08:36.838
In other words, the hash function,

00:08:36.838 --> 00:08:39.617
as long as it's collision resistant,

00:08:39.617 --> 00:08:42.105
it will result in a
secure signature scheme

00:08:42.105 --> 00:08:44.250
for this hash and sign paradigm.

00:08:44.250 --> 00:08:45.822
Okay, now you can
probably think about this

00:08:45.822 --> 00:08:47.621
for a moment, but if you
could find, let's say,

00:08:47.621 --> 00:08:50.246
two input messages that are distinct

00:08:50.246 --> 00:08:51.913
and that map to the same output

00:08:51.913 --> 00:08:54.552
under an application of the hash function,

00:08:54.552 --> 00:08:57.313
that would, in fact, lead
to some bizarre problems

00:08:57.313 --> 00:09:00.248
because a signature on the first message

00:09:00.509 --> 00:09:01.324
would then be identical

00:09:01.324 --> 00:09:03.003
to a signature on the second message

00:09:03.003 --> 00:09:04.220
since in both cases, what you're doing

00:09:04.220 --> 00:09:05.864
is you're not signing the actual message.

00:09:05.864 --> 00:09:07.292
You're signing the hash of the message.

00:09:07.292 --> 00:09:09.425
So, if the hashes are identical,

00:09:09.425 --> 00:09:10.908
you'll end up with the identical signature

00:09:10.908 --> 00:09:12.600
on two different messages,

00:09:12.600 --> 00:09:14.266
and that could create problems

00:09:14.266 --> 00:09:16.322
like making it easy for
maybe a particular message

00:09:16.322 --> 00:09:20.039
to be forged under this
digital signature approach,

00:09:20.039 --> 00:09:22.084
and that's obviously
something that you don't want.

00:09:22.084 --> 00:09:23.852
you don't want someone to be able to

00:09:23.852 --> 00:09:26.388
come up with a signature
on a different message,

00:09:26.388 --> 00:09:28.772
as opposed to maybe the
one that you initially

00:09:28.772 --> 00:09:31.289
intended to sign.

00:09:31.289 --> 00:09:34.810
Now, it is possible, and I
just want to make this clear,

00:09:34.810 --> 00:09:37.400
it's possible to describe
digital signatures

00:09:37.400 --> 00:09:39.488
with a lot more mathematical formalism,

00:09:39.488 --> 00:09:41.857
but my hope with this video
really was to give you

00:09:41.857 --> 00:09:43.685
a flavor, if you will,
without drilling into

00:09:43.685 --> 00:09:46.777
all of the underlying
nuances in mathematics.


Bitcoin - Cryptographic hash function

WEBVTT
Kind: captions
Language: en

00:00:00.835 --> 00:00:02.138
Voiceover: Cryptographic hash functions

00:00:02.138 --> 00:00:04.199
are basically fundamental building blocks

00:00:04.199 --> 00:00:07.201
that are used within many
cryptographic algorithms

00:00:07.201 --> 00:00:08.051
and protocols,

00:00:08.051 --> 00:00:09.631
and they have a number of very important

00:00:09.631 --> 00:00:13.090
applications in the context
of information security

00:00:13.090 --> 00:00:14.577
as a whole.

00:00:14.577 --> 00:00:16.135
Now, some of the more common algorithms

00:00:16.135 --> 00:00:17.575
in this category that are known

00:00:17.575 --> 00:00:20.119
as cryptographic has functions include:

00:00:20.119 --> 00:00:22.848
things like MD5, and also,

00:00:22.848 --> 00:00:26.438
it has some predecessors
like MD4 and others,

00:00:26.438 --> 00:00:29.877
as well as algorithms like SHA-256,

00:00:29.877 --> 00:00:32.941
and actually, SHA-256 is preceded

00:00:32.941 --> 00:00:36.822
by other algorithms like SHA-1 and so on,

00:00:36.822 --> 00:00:38.645
and also there are some algorithms

00:00:38.645 --> 00:00:40.668
that maybe you've heard of,

00:00:40.668 --> 00:00:42.543
or maybe that are a bit lesser known,

00:00:42.543 --> 00:00:45.040
but things like RIPEMD,
and BLAKE, and Skein,

00:00:45.040 --> 00:00:46.109
and others.

00:00:46.109 --> 00:00:48.543
Now, cryptographic hash
functions are basically

00:00:48.543 --> 00:00:52.090
used as critical building
blocks in many applications,

00:00:52.090 --> 00:00:54.671
and really the first
motivating application,

00:00:54.671 --> 00:00:56.751
the first historical application

00:00:56.751 --> 00:00:58.591
of these types of hash functions

00:00:58.591 --> 00:01:00.922
was in the context of what's known

00:01:00.922 --> 00:01:03.198
as a digital signature,

00:01:03.198 --> 00:01:05.735
and digital signatures are
used in so many different

00:01:05.735 --> 00:01:07.838
cryptographic applications today.

00:01:07.838 --> 00:01:09.759
They're the cornerstone of many

00:01:09.759 --> 00:01:11.572
ecommerce protocols.

00:01:11.572 --> 00:01:14.255
They are used in doing things
like bitcoin generation

00:01:14.255 --> 00:01:15.593
and so on.

00:01:15.593 --> 00:01:17.326
Cryptographic has functions are also used

00:01:17.326 --> 00:01:20.569
in things like message
authentication protocols,

00:01:20.569 --> 00:01:22.810
in pseudorandom number generation

00:01:22.810 --> 00:01:24.589
and password security,

00:01:24.589 --> 00:01:26.903
even encryption to some degree.

00:01:26.903 --> 00:01:30.820
In fact, aside from their
use in digital signatures,

00:01:30.820 --> 00:01:33.069
these hash functions are
also used in other places

00:01:33.069 --> 00:01:35.738
in the bitcoin protocol as well.

00:01:35.738 --> 00:01:37.082
First of all, let me talk about

00:01:37.082 --> 00:01:39.986
what a cryptographic hash
function actually is,

00:01:39.986 --> 00:01:42.036
and of course, as the name implies,

00:01:42.036 --> 00:01:43.284
the first thing it is,

00:01:43.284 --> 00:01:44.651
it's a hash function.

00:01:44.651 --> 00:01:45.546
And by hash function,

00:01:45.546 --> 00:01:48.601
I basically mean that it will take input.

00:01:48.601 --> 00:01:49.889
It's a mathematical function,

00:01:49.889 --> 00:01:51.655
a transformation, if you will,

00:01:51.655 --> 00:01:54.101
that takes a particular input,

00:01:54.101 --> 00:01:57.432
and we call this input a message,

00:01:57.432 --> 00:01:59.864
and the message can be
of arbitrary length,

00:01:59.864 --> 00:02:01.990
and the hash function basically applies

00:02:01.990 --> 00:02:04.442
a mathematical transformation,

00:02:04.442 --> 00:02:06.460
or maybe a set of
mathematical transformations

00:02:06.460 --> 00:02:09.281
to this input to produce a single output,

00:02:09.281 --> 00:02:11.861
and we typically call
this output a digest,

00:02:11.861 --> 00:02:13.698
although, sometimes you will see

00:02:13.698 --> 00:02:17.597
the output referred to
as a tag, or as a hash,

00:02:17.597 --> 00:02:19.223
or as a fingerprint,

00:02:19.223 --> 00:02:22.112
but digest is sort of the
most common nomenclature.

00:02:22.112 --> 00:02:24.274
In fact, MD5, which was

00:02:24.274 --> 00:02:26.605
one of the earlier hash functions,

00:02:26.605 --> 00:02:29.370
stands for message digest 5,

00:02:29.370 --> 00:02:30.935
and MD4 was message digest 4,

00:02:30.935 --> 00:02:32.781
and so on, and so forth.

00:02:32.781 --> 00:02:35.543
Now, the message, as I mentioned briefly

00:02:35.543 --> 00:02:36.843
can be of arbitrary size.

00:02:36.843 --> 00:02:38.488
It can be as long as you want,

00:02:38.488 --> 00:02:40.360
or as short as you want,

00:02:40.360 --> 00:02:41.214
but the output,

00:02:41.214 --> 00:02:44.108
the size of the digest
or the size of the tag,

00:02:44.108 --> 00:02:45.783
is going to be fixed in length,

00:02:45.783 --> 00:02:48.221
and for example, in the
context of a hash function

00:02:48.221 --> 00:02:50.777
like, let's say, SHA-256,

00:02:50.777 --> 00:02:56.114
the digest will actually be
exactly 256 bits in length.

00:02:56.114 --> 00:02:57.917
It's going to have a fixed-length output,

00:02:57.917 --> 00:03:01.654
but an arbitrary-length input.

00:03:01.654 --> 00:03:02.626
The other thing I want to point out

00:03:02.626 --> 00:03:04.445
about these cryptographic hash functions

00:03:04.445 --> 00:03:06.943
is that the function here
is a deterministic function,

00:03:06.943 --> 00:03:07.712
and by that, I mean

00:03:07.712 --> 00:03:11.281
that the output will always be the same

00:03:11.281 --> 00:03:12.365
for a given input,

00:03:12.365 --> 00:03:14.112
so if you have a given input,

00:03:14.112 --> 00:03:15.490
you're going to see the exact same output.

00:03:15.490 --> 00:03:17.112
You won't have a
situation in which, maybe,

00:03:17.112 --> 00:03:19.344
a given input will have two
different possible outputs.

00:03:19.344 --> 00:03:21.698
It's going to be consistent.

00:03:21.698 --> 00:03:25.151
Now, traditional hash functions have been

00:03:25.151 --> 00:03:27.841
used in computer science
for quite some time,

00:03:27.841 --> 00:03:29.115
and they are used in many

00:03:29.115 --> 00:03:30.156
computing applications,

00:03:30.156 --> 00:03:31.506
so, for example, you may
have heard of something

00:03:31.506 --> 00:03:33.065
like a hash function used in something

00:03:33.065 --> 00:03:34.973
called a hash table,

00:03:34.973 --> 00:03:37.255
but the kinds of hash
functions that are used

00:03:37.255 --> 00:03:39.935
in hash tables, and I want to stress this,

00:03:39.935 --> 00:03:42.396
they aren't necessarily the same

00:03:42.396 --> 00:03:44.530
as cryptographic hash functions.

00:03:44.530 --> 00:03:48.159
The qualifier "cryptographic"
here is very important,

00:03:48.159 --> 00:03:50.964
and it usually means or implies that

00:03:50.964 --> 00:03:53.695
that hash function has
to have a certain set

00:03:53.695 --> 00:03:56.656
of critical design goals and maybe some

00:03:56.656 --> 00:03:57.988
particular properties in mind

00:03:57.988 --> 00:04:00.209
that make it suitable for use

00:04:00.209 --> 00:04:02.109
in applications that use cryptography

00:04:02.109 --> 00:04:03.397
or cryptographic applications,

00:04:03.397 --> 00:04:06.646
areas where perhaps security or privacy

00:04:06.646 --> 00:04:08.639
or confidentiality or authentications

00:04:08.639 --> 00:04:11.596
are a serious concern.

00:04:11.596 --> 00:04:12.354
First and foremost,

00:04:12.354 --> 00:04:13.986
maybe in describing
some of these properties

00:04:13.986 --> 00:04:17.090
is that, and maybe this
almost goes without saying,

00:04:17.090 --> 00:04:18.599
one of the first properties you want

00:04:18.599 --> 00:04:19.828
of a cryptographic hash function

00:04:19.828 --> 00:04:24.544
is that it should be
computationally efficient,

00:04:24.544 --> 00:04:27.213
and by that, I mean that it
shouldn't take a lot of time

00:04:27.213 --> 00:04:30.882
to compute the output from a given input.

00:04:30.882 --> 00:04:32.588
If you're given a message

00:04:32.588 --> 00:04:34.900
and you want to apply this
set of transformations

00:04:34.900 --> 00:04:37.332
to that message to get a digest,

00:04:37.332 --> 00:04:40.560
that set of transformation
should not take a long time

00:04:40.560 --> 00:04:41.888
to implement on a computer.

00:04:41.888 --> 00:04:43.907
It should be very fast,
or relatively fast.

00:04:43.907 --> 00:04:45.049
It almost goes without saying,

00:04:45.049 --> 00:04:47.327
but I think it's important
to stress and point it out

00:04:47.327 --> 00:04:49.402
because I've seen people come up

00:04:49.402 --> 00:04:51.714
with grossly inefficient
hash functions sometimes,

00:04:51.714 --> 00:04:54.007
and those would not be considered suitable

00:04:54.007 --> 00:04:56.548
in the context of when typical

00:04:56.548 --> 00:04:58.087
cryptographic hash functions are used

00:04:58.087 --> 00:05:01.210
for cryptographic applications.

00:05:01.210 --> 00:05:02.865
The second property you typically need

00:05:02.865 --> 00:05:03.627
in the context,

00:05:03.627 --> 00:05:06.647
and this is especially in the
context of digital signing,

00:05:06.647 --> 00:05:08.261
is that you want it to be the case

00:05:08.261 --> 00:05:11.768
that it's hard to find two
inputs that actually map

00:05:11.768 --> 00:05:12.802
to the same output,

00:05:12.802 --> 00:05:14.438
and I mean two distinct inputs

00:05:14.438 --> 00:05:17.920
whose corresponding digest is identical.

00:05:17.920 --> 00:05:20.460
This property is typically referred to as

00:05:20.460 --> 00:05:24.355
collision resistance.

00:05:24.355 --> 00:05:28.798
That means it's hard to find
a colliding pair of input,

00:05:28.798 --> 00:05:30.886
so in other words, if you have two inputs

00:05:30.886 --> 00:05:32.518
and let's say you have a message M1,

00:05:32.518 --> 00:05:34.981
and you have a message M2,

00:05:34.981 --> 00:05:36.674
their output under the application

00:05:36.674 --> 00:05:40.174
of the hash function
should not be the same.

00:05:40.174 --> 00:05:42.529
You won't ever have it
be the same that the,

00:05:42.529 --> 00:05:44.133
you won't even have it
be the case, rather,

00:05:44.133 --> 00:05:46.206
that the output of M1 and M2

00:05:46.206 --> 00:05:47.907
under an application of the hash function

00:05:47.907 --> 00:05:48.872
is the same.

00:05:48.872 --> 00:05:50.207
They should never be the same.

00:05:50.207 --> 00:05:52.145
It should always be different.

00:05:52.145 --> 00:05:54.301
Now, I should take a step back here

00:05:54.301 --> 00:05:57.879
and point out that of course in practice,

00:05:57.879 --> 00:06:00.304
given that messages can
be of arbitrary size

00:06:00.304 --> 00:06:03.280
and given that the input
or the output, rather,

00:06:03.280 --> 00:06:04.945
is a fixed size,

00:06:04.945 --> 00:06:08.903
it's not mathematically
possible to guarantee

00:06:08.903 --> 00:06:11.402
that the output will always be different

00:06:11.402 --> 00:06:13.039
for two distinct messages,

00:06:13.039 --> 00:06:15.205
but what you typically want
is not that the outputs

00:06:15.205 --> 00:06:16.734
are necessarily different,

00:06:16.734 --> 00:06:19.707
but that it's hard to
find two distinct messages

00:06:19.707 --> 00:06:21.436
that produce the same output.

00:06:21.436 --> 00:06:23.159
We know they exist by virtue of the fact

00:06:23.159 --> 00:06:25.441
that there are many
messages that can be hash,

00:06:25.441 --> 00:06:28.287
and only a finite, small number,

00:06:28.287 --> 00:06:29.508
relatively small number compared to

00:06:29.508 --> 00:06:30.839
the number of messages,

00:06:30.839 --> 00:06:34.166
a smaller number of
possible digest values,

00:06:34.166 --> 00:06:36.602
but aside from that consideration,

00:06:36.602 --> 00:06:38.869
it should be hard. It
should take a long time,

00:06:38.869 --> 00:06:42.206
and by long, I mean an
astromonically long time

00:06:42.206 --> 00:06:45.011
to find two distinct
messages that would result

00:06:45.011 --> 00:06:47.047
in the same output

00:06:47.047 --> 00:06:51.397
under the application
of the hash function.

00:06:51.397 --> 00:06:52.902
Now, the third thing
that I want to point out

00:06:52.902 --> 00:06:55.706
is that in many cases, you might want,

00:06:55.706 --> 00:06:57.427
also, in the context of a hash function,

00:06:57.427 --> 00:06:59.638
for the hash function to be able to hide

00:06:59.638 --> 00:07:01.585
information about the inputs.

00:07:01.585 --> 00:07:02.375
In other words,

00:07:02.375 --> 00:07:06.186
given the output,

00:07:06.186 --> 00:07:08.922
it should be hard to glean anything useful

00:07:08.922 --> 00:07:11.756
or interesting about the input.

00:07:11.756 --> 00:07:13.615
Anything, any relevant detail,

00:07:13.615 --> 00:07:15.323
and I don't just mean the whole input,

00:07:15.323 --> 00:07:16.891
but maybe even something as simple as

00:07:16.891 --> 00:07:19.384
was the input an even
number or an odd number?

00:07:19.384 --> 00:07:20.343
I mean, that should be the kind of thing

00:07:20.343 --> 00:07:24.357
that should be hard to infer
when you see the output,

00:07:24.357 --> 00:07:26.401
even something as simple as the,

00:07:27.631 --> 00:07:30.648
the evenness or oddness of the input.

00:07:30.648 --> 00:07:32.571
Now, a fourth property I want to point out

00:07:32.571 --> 00:07:35.584
is that you typically
want the output to be

00:07:36.153 --> 00:07:37.559
well distributed.

00:07:37.559 --> 00:07:38.158
In other words,

00:07:38.158 --> 00:07:43.358
the output should look random.

00:07:43.358 --> 00:07:44.545
In other words, it should look

00:07:44.545 --> 00:07:46.395
like a set of coin flips took place,

00:07:46.395 --> 00:07:49.149
not that there was a predictable way

00:07:49.902 --> 00:07:53.515
in which the output was created.

00:07:54.146 --> 00:07:55.586
Really, what that means is that,

00:07:55.586 --> 00:07:57.454
and you can think of it
maybe more conceptually as

00:07:57.454 --> 00:07:59.473
it's almost as if you
flipped a bunch of coins

00:07:59.473 --> 00:08:00.426
to get to the output.

00:08:00.426 --> 00:08:02.808
It should look just that random.

00:08:02.808 --> 00:08:04.123
And so what you can maybe think of

00:08:04.123 --> 00:08:05.838
cryptographic hash functions as,

00:08:05.838 --> 00:08:07.994
as it's, perhaps, maybe
the mathematical equivalent

00:08:07.994 --> 00:08:11.237
or mathematical analog of
a meat grinder of sort.

00:08:11.237 --> 00:08:12.724
It can take inputs and apply

00:08:12.724 --> 00:08:15.807
these mathematical transformations to them

00:08:15.807 --> 00:08:18.169
such that the output looks,

00:08:18.169 --> 00:08:19.745
for all intents and purposes,

00:08:19.745 --> 00:08:21.406
completely random and unrelated

00:08:21.406 --> 00:08:23.979
to the original input.

00:08:23.979 --> 00:08:25.548
I do want to make a few quick remarks

00:08:25.548 --> 00:08:28.019
about these particular properties,

00:08:28.019 --> 00:08:31.132
and first of all, they are interrelated.

00:08:31.132 --> 00:08:33.014
For example, if you have a situation

00:08:33.014 --> 00:08:34.581
where the outputs, let's say,

00:08:34.581 --> 00:08:37.660
really appear to bear no
relationship to the input

00:08:37.660 --> 00:08:40.127
and the outputs also look random,

00:08:40.127 --> 00:08:42.596
then that will, in fact,
give you to a large degree,

00:08:42.596 --> 00:08:44.694
a lot of the collision
resistance properties

00:08:44.694 --> 00:08:46.842
because just the fact that you can't

00:08:46.842 --> 00:08:47.754
predict the output

00:08:47.754 --> 00:08:49.933
and the fact that it
hides all this information

00:08:49.933 --> 00:08:52.754
implies that it's going to be hard to find

00:08:52.754 --> 00:08:54.098
two inputs that are distinct

00:08:54.098 --> 00:08:55.993
that map to the same output.

00:08:55.993 --> 00:08:57.245
And so sometimes, you get one property

00:08:57.245 --> 00:08:59.097
in exchange for the others.

00:08:59.097 --> 00:09:00.083
The second thing I want to point out

00:09:00.083 --> 00:09:03.160
is that typically, these
properties in practice,

00:09:03.160 --> 00:09:05.775
or maybe in the underlying mathematics,

00:09:05.775 --> 00:09:07.626
are things that you hope for

00:09:07.626 --> 00:09:09.753
but you can't always guarantee

00:09:09.753 --> 00:09:11.426
that they'll always hold,

00:09:11.426 --> 00:09:14.158
and it may be entirely possible that

00:09:14.158 --> 00:09:15.363
you could design a hash function

00:09:15.363 --> 00:09:18.506
that you think is completely
collision resistant,

00:09:18.506 --> 00:09:20.817
but someone might come
along a year from now

00:09:20.817 --> 00:09:23.420
and come up with a more
clever way for finding

00:09:23.420 --> 00:09:23.983
a collision.

00:09:23.983 --> 00:09:25.217
Maybe they'll find a clever shortcut

00:09:25.217 --> 00:09:28.001
that does not involve
doing a brute force search

00:09:28.001 --> 00:09:29.265
of any sort.

00:09:29.265 --> 00:09:31.155
It turns out that cryptographers,

00:09:31.155 --> 00:09:34.128
for better or worse currently do not have

00:09:34.512 --> 00:09:35.895
any mathematical techniques.

00:09:35.895 --> 00:09:37.500
They haven't developed
techniques for being able

00:09:37.500 --> 00:09:40.118
to work around some of these limitations.

00:09:40.118 --> 00:09:43.824
So we often do take it on face value

00:09:43.824 --> 00:09:45.191
that these schemes are secure

00:09:45.191 --> 00:09:48.207
based on how long they've been around.

00:09:48.207 --> 00:09:49.464
Now, I also want to point out,

00:09:49.464 --> 00:09:50.459
and the last thing I want to point out,

00:09:50.459 --> 00:09:51.873
is that this treatment that I've given

00:09:51.873 --> 00:09:53.996
is not meant to be mathematically rigorous

00:09:53.996 --> 00:09:55.763
by any stretch of the imagination.

00:09:55.763 --> 00:09:59.503
There are far more
precise ways to describe

00:09:59.503 --> 00:10:01.172
these underlying properties,

00:10:01.172 --> 00:10:03.273
but my hope, instead, is that

00:10:03.273 --> 00:10:05.921
this video gives you,
maybe, a bit of a flavor

00:10:05.921 --> 00:10:08.634
for what is required of a
cryptographic hash function

00:10:08.634 --> 00:10:11.164
without maybe getting
bogged down in some of the

00:10:11.164 --> 00:10:13.520
mathematical minutia and formalism.