字幕記錄


00:00
okay so we're in the middle of
00:05
explaining Bitcoin design and I've
00:08
gotten to the point of ask of wanting
00:11
there to be a global published record of
00:16
all the transactions all right okay and
00:24
this is this requirement is very similar
00:27
to the requirement for certificate
00:29
transparency from last week and the
00:31
solution is somewhat reminiscent
00:34
although more sophisticated then
00:37
certificate transparency solution and a
00:40
name we want a public log this is often
00:42
also called a public ledger okay so how
00:46
are we going to build ourselves a public
00:47
ledger so that everybody agrees on all
00:49
the transactions that have already
00:51
happened and further when they agree on
00:53
the order of the transactions because if
00:55
Y tries to send this coin to both Z and
00:59
Q at the same time you know we want the
01:01
first one to win and the second one to
01:02
be ignored
01:03
whatever Yellin which one want which
01:06
transaction was came first and which
01:08
came second and should be ignored okay
01:10
so how to make a ledger so here's a bad
01:15
idea
01:19
well a good idea actually have the most
01:21
simplest idea is to just pick somebody
01:23
who everybody trusts and have that
01:25
somebody maintain the ledger for you
01:27
every time you want to do transaction
01:29
you tell the trusted entity what the
01:31
transaction is it just accumulates a log
01:33
and it's willing to give a copy of that
01:35
log to anyone so anyone can inspect it
01:37
and see if coins already been spent and
01:38
that actually is a good idea and if you
01:41
could possibly do it you should for
01:44
various reasons the Bitcoin designers
01:46
rejected this very obvious
01:47
straightforward idea and the fundamental
01:51
reason is that in a big system in a
01:54
worldwide system there's unlikely to be
01:57
any single entity that everyone trusts
02:00
and that is indeed trustworthy and has
02:01
no corrupt employees for example and in
02:05
a global system you know that means that
02:07
we can't have the United States you know
02:09
government
02:10
I'm the trusted entity because there's
02:12
plenty of governments in the world to
02:13
don't necessarily trust the United
02:15
States similarly for any other
02:18
individual government so really for a
02:20
global system there's no it's it's easy
02:23
to argue against the idea of having a
02:24
single central trusted entity so that
02:27
leaves us way as well we want to run the
02:29
system make a system that's built out of
02:31
mutually untrusting participants where
02:36
we can survive malice by you know by
02:41
their participants okay so here's a
02:43
here's a bad possibility let's just let
02:48
anybody let's build a system on which
02:50
anybody can join so it's gonna have
02:52
thousands maybe if computers will call
02:54
them peers they're scattered all over
02:55
the Internet
02:56
and each one of them is going to be
02:58
running the software to for our new
03:03
cryptocurrency system anytime somebody
03:07
wants to have a new transaction like Y
03:10
wants to send a coin to Z Y floods their
03:19
new transaction sends their new
03:21
transaction to all the peers to send
03:23
them directly or another design which is
03:26
actually what Bitcoin uses is that Y
03:28
sends a new transaction to a couple the
03:30
peers and then the peers afford it sort
03:33
of over individual TCP links to the
03:38
entire rest of the system so in every
03:39
transaction ends up being sent to all
03:41
the peers and the peers what they're
03:43
trying to do is each of them maintain a
03:46
complete copy of the log of all
03:48
transactions and what we really want is
03:50
for all the peers used all the honest
03:54
peers for their transaction logs to be
03:56
identical they'll agree on which
03:58
transactions exist and just as important
04:01
on the order of those transactions so
04:03
how can we arrange for all these peers
04:05
to end up processing the heading
04:09
transactions they're logs in the same
04:11
order remember of course why may have
04:13
sent the transaction to Z you know to
04:16
these peers and at the same time sent
04:19
its transaction to Q to some other set
04:22
of peers and we want to make sure that
04:25
despite that the peers end up with the
04:30
same with identical logs even if Y is
04:32
trying to treat well I actually don't
04:36
know how to design this one possibility
04:39
that you can imagine is that the peers
04:43
would somehow talk to each other about
04:45
each new transaction and for each new
04:48
slot in the log would vote on what
04:50
transaction should fill that slot and
04:54
have the majority you know since they
04:56
may disagree legitimately if they
04:58
received different transactions we have
05:00
a majority rule that says well we're
05:02
gonna all the peers are gonna look at
05:03
all the votes and the transaction that
05:05
gets the most votes is the one that will
05:07
go in the next slot in the log and then
05:09
they'll vote again on the next slide and
05:15
you know maybe you could get this to
05:17
work you'd have to know who all the
05:19
other peers are in order to know what a
05:21
majority is you don't have to know how
05:22
many peers there are and you really want
05:25
to make sure that you never count any
05:27
peer more than once but in a completely
05:30
open system like Bitcoin actually we
05:33
can't do either of those things we don't
05:34
know how many participants there are in
05:36
Bitcoin and furthermore the number
05:38
changes all the time as people peers
05:41
join and leave the system so we don't
05:43
know how many peers are so we don't know
05:44
what a majority would be furthermore we
05:47
don't have a way to reliably count votes
05:50
such that each participant only gets one
05:52
vote even assuming that was desirable
05:56
for example so we can't use IP addresses
05:59
in order to decide it's distinct votes
06:03
we can't say well each IP address gets
06:04
one vote or at most one vote because it
06:07
turns out to be extremely easy to either
06:09
forge I P addresses or by breaking into
06:12
people's computers to accumulate tens of
06:15
thousands of real computers that you can
06:18
control and you of course would you can
06:21
get them all to vote on your
06:25
and you can get them all to vote in the
06:28
system so an attacker could probably
06:29
accumulate a majority of votes
06:31
relatively easily in a sort of
06:34
straightforward design like this and if
06:36
an attacker can can get a majority of
06:38
the votes then it can use this majority
06:44
to sit to sort of say different things
06:47
conflicting things but with the majority
06:49
each time so if Z asks the system oh you
06:53
know with which which of the two
06:57
transactions came first cuz you know
06:59
that remember the problem were worried
07:02
about is that y is gonna double spend
07:03
some coin so it's gonna spend the same
07:06
coin - Q wants you to believe that and
07:09
it's gonna send that same Q's coin to Z
07:13
and 1c to believe that so maybe when Q
07:15
asks what's the next transaction to log
07:17
the majority controlled by the attacker
07:19
can say oh you know wise transfer to Q
07:21
is the very next one in the log and that
07:22
comes before this transaction and when Z
07:26
asks maybe the attackers majority will
07:28
say well you know the transfer Z comes
07:30
first and this other transaction to Q
07:33
comes second and that would mean the
07:36
attacker can trick q + Z into X into
07:40
accepting the same coin that's a double
07:43
spend and that's a disaster so without
07:48
some very clever idea it's very hard to
07:50
build an open system
07:52
you know without a controlled
07:54
memberships very hard to build an open
07:56
system in which you have reliable voting
08:01
okay but in fact Bitcoin doesn't quite
08:06
use voting but it nevertheless manages
08:09
to solve this problem of how to get
08:13
agreement on a single ledger
08:14
despite malice so this is the Bitcoin
08:18
blockchain
08:26
and at this point there's a lot of diff
08:29
chain systems out there so actually I'm
08:31
not even sure what blockchain as a term
08:33
refers to but I'm only talking about
08:36
Bitcoin right now okay so the goal is we
08:41
want agreement on a single transaction
08:43
log again because we want to prevent
08:46
double spending and this we're going to
08:50
be building Bitcoin builds this thing
08:52
called the blockchain that contains all
08:55
the transactions on all the coins so
08:57
it's a single a single blockchain that
09:00
describes all the transactions in the
09:02
system again as with the previous system
09:06
there's going to be many peers so we
09:08
still have this kind of overlay network
09:10
appears each peer is kind of building a
09:15
copy of the log and a complete copy of
09:18
the transaction log in its own memory
09:21
and we don't know how many peers they
09:25
are or how many there are who they are
09:27
but they form a sort of in one of these
09:30
overlay networks spotted with TCP
09:32
connections and anytime a peer hears
09:35
about a new transaction like when Y
09:37
wants to submit a payment transaction to
09:39
Z or Q it's gonna send it to one or more
09:41
peers and that peers gonna flood the
09:43
transaction over the whole system the
09:47
way the log is built up the way that
09:50
blockchain is built up is that each of
09:52
the peers accumulates transactions and
09:54
PACs many transactions thousands into a
09:57
block and then it's entire new blocks of
10:01
transactions that are really appended to
10:03
the ledger again by flooding new blocks
10:06
over the whole system so that at least
10:08
in theory every peer sees every new
10:10
blocks so the blockchain model
10:17
blockchains consists of blocks what each
10:19
block looks like is the hash of the
10:26
previous block it's a bit like my
10:32
previous transaction broken transaction
10:35
system so we have the hash of the
10:36
previous block like cryptographic hash
10:42
of the previous block there's a set of
10:44
transactions so these are individual
10:46
spans from you know why is trying to pay
10:51
queue or whatever it happens to be a
10:54
couple hundred of whole thousand
10:56
individual transactions and each
10:57
transaction is actually much as I
11:00
described before it has the hash of the
11:04
previous transaction for that coin which
11:06
is going to exist in a previous block
11:07
typically it has deprived a signature by
11:10
the private key of the previous owner of
11:13
that coin and it is the public key of
11:14
the new owner so this transaction would
11:16
have that transfers money from why the
11:20
queue would contain Hugh's public key
11:24
and a signature by with wise private key
11:27
plus a hash of a previous transaction in
11:30
a previous block as well as these
11:34
transactions there's a nonce
11:38
which I'll talk about in a moment it's
11:39
just a 32-bit number and then the
11:43
current time roughly the way the system
11:49
works is that the peers accumulate new
11:52
transactions and roughly every 10
11:53
minutes one of them produces a new block
11:56
that should be the successor block
11:58
containing all the transactions that
12:00
have been sort of sent into the system
12:01
in the ten minutes roughly since the
12:03
previous block was created and if you're
12:08
if somebody tells you they're paying you
12:11
Bitcoin then before you accept that
12:14
they've really done it you need to watch
12:16
the blockchain as it evolves and you
12:18
know blocks new blocks are signs
12:19
everywhere so the blockchain is quite
12:21
public if you think somebody claims to
12:24
have paid you you need to watch the
12:26
blockchain until you see a new block
12:28
that contains the transaction that
12:32
you're expecting from the person that
12:35
claimed to sent you money and with your
12:37
public key at them that looks a valid
12:39
you know correctly signed okay so
12:42
everybody everybody has to watch the
12:45
blockchain for payments to them all
12:52
right so who creates each block this
12:55
action of creating a new block is called
12:57
mining and the technique that's used to
13:00
produce a new block is often also called
13:02
proof of work in the sense that it
13:05
requires a lot of CPU time to produce a
13:08
new block and so the production of a new
13:09
block essentially proves that you
13:12
control a real live CPU and you're not
13:14
just mining new blocks on a fake
13:18
computer the new block
13:25
in order to be valid a new block when
13:29
you hash it has to have a certain number
13:32
of zeros at the beginning of the hash of
13:35
the block now of course if you just take
13:39
a bunch of arbitrary transactions and
13:41
you do a cryptographic hash on it it's
13:43
highly unlikely that the hash of some
13:45
just whatever data is gonna have more
13:48
than one or two or three zeros at the
13:52
beginning of the cryptographic hash
13:54
however the computer that's mining the
14:00
block can put any value it likes here
14:02
for the knots and so what the mining
14:04
computers do is that they try different
14:07
by different random values for the nonce
14:09
just pick one with a random number
14:11
generator that'll stick it in there copy
14:13
of the block they're trying to mine and
14:14
then they'll compute the hash on the
14:16
block
14:16
and they'll check how many zeros how
14:18
many leading zeros are in the hash with
14:20
this particular knots if it's enough
14:22
leading zeros I don't know how many it
14:24
is but it's you know sort of on the
14:26
order of dozens if there's enough
14:28
leading zeros and it's a valid mine a
14:30
valid block and the whatever peer it was
14:34
that found this nonce that caused the
14:36
block hash to have lots of leading zeros
14:38
can flood this block over the network
14:40
and you know all that's being equal
14:43
that'll be the new next block and the
14:45
chain but typically the the hash of the
14:51
block with any given nonce you know
14:52
won't have enough leading zeros and the
14:55
mining the peer will have to try another
14:57
nonce another random nonce keep doing
14:59
that until it gets uh a block that
15:01
hashes to a hash with enough leading
15:03
zeros and so this takes a lot of CPU
15:05
time it takes oh you know it's a random
15:07
process but the system is sort of tuned
15:11
and the number of zeros that are
15:13
required to exist at the beginning of
15:16
the hash of the block is set so that it
15:19
takes about ten minutes you know with
15:22
all the different peers hundreds of
15:23
thousands appears out there who are
15:25
doing Bitcoin mining the average amount
15:28
of time before the first one of them
15:29
finds a nonce for a block that has
15:33
enough feeding zeros is set up to be ten
15:36
minutes
15:38
okay so question how do peers or new
15:44
peers discover other peers to
15:46
communicate with yeah it's a great
15:48
question so this is sort of a reference
15:50
to the this network of Bitcoin peers if
15:54
I'm a new peer you know I've install a
15:57
new computer I get Bitcoin software
15:58
installed on my my computer and I want
16:00
to join the Bitcoin network how do I
16:03
know who to talk to and how do I know
16:06
well so the straightforward answer to
16:09
that is that the Bitcoin software has
16:11
built into it on the IP addresses of a
16:15
whole bunch of current peers and so your
16:17
software when you first fire it up into
16:19
the binary the source whatever the
16:21
Bitcoin software you know has a whole
16:24
bunch of IP addresses and you try to
16:25
make TCP connections to those existing
16:30
peers and if all goes well you'll be
16:32
able to connect to them and you'll say
16:33
look I'm new please give me a copy of
16:34
the blockchain as it exists now and
16:37
they'll send you the current block team
16:40
which is about a couple hundred
16:42
gigabytes right now so that's if all
16:46
goes well if all doesn't go well then
16:50
you may run into problems like for
16:52
example if your copy of the software has
16:54
been modified by somebody malicious to
16:56
have a list of IP addresses that are all
16:59
controlled by the attacker or the
17:02
attacker controls your computer network
17:05
so that regardless of who you try to
17:07
connect to you end up actually talking
17:09
to the attackers machines it may be that
17:11
the attacker is running you know their
17:13
own isolated network and that you know
17:17
you think your newly installed software
17:19
thinks it's made a bunch of connections
17:21
the Bitcoin knows but whoops they're all
17:23
attackers nodes in that case a
17:25
blockchain you'll get will be watching
17:28
controlled by the attacker
17:29
and you may well you will be in trouble
17:31
and you know there's pick one of some
17:36
defenses against this may be the main
17:41
well he
17:44
loaded correct Bitcoin software the
17:48
correct Bitcoin software has built-in
17:50
hashes of recent blocks in the
17:52
blockchain and that means that if you
17:54
connect to some attackers in your
17:56
running proper Bitcoin software at least
17:59
the Bakhtin has to start with the first
18:05
however many thousand blocks in the box
18:07
beam have to be correct if you download
18:09
it absolutely wrong software modified by
18:11
the attacker then there's just nothing
18:13
Bitcoin can do to help you then this is
18:16
a potential weakness in the system I
18:19
haven't necessarily heard of anybody
18:20
exploiting this but it's definitely
18:26
something to think about
18:28
ok back to mining ok so the if you want
18:33
to create a new block you gotta find a
18:34
nonce that causes the new block you're
18:38
trying to produce causes hash to have
18:40
lots of leading zeros for an individual
18:43
machine you know the amount of time for
18:47
an individual ordinary computer to find
18:48
a nonce that satisfies this requirement
18:50
is like at least in a months of CPU time
18:54
but there's a very large number of
18:57
Bitcoin miners out there and so even
19:00
though any one of them would take a very
19:01
long time to find a new block or we
19:04
really care about is the time for the
19:05
very first one of them to find a block
19:07
and since they're all making these sort
19:09
of random choices of nonce one of them
19:12
is gonna find a a nonce that fulfills
19:17
the requirements relatively soon and the
19:20
number a Bitcoin adjusts the number of
19:22
leading required leading zeros in the
19:24
hash in response to how fast new blocks
19:29
seemed to be appearing and so if new
19:32
blocks are appearing much faster than
19:33
once every 10 minutes Bitcoin will
19:36
automatically increase the number of
19:38
leading zeros that's required and
19:39
that'll make it correspondingly harder
19:41
and take longer for the miners to find a
19:44
a new block Nana blocks are of course
19:47
arriving slower than every 10 minutes
19:48
over a sustained period of time then
19:50
Bitcoin will adjust the required number
19:52
of leading zeroes in the hash to be
19:54
smaller and that means it'll be easier
19:56
quicker
19:57
to find you blocks to the sort of an
19:59
adaptive scheme there to us blocks to
20:04
new boxes show up run once every ten
20:05
minutes roughly okay so this is the
20:09
proof-of-work scheme and this is
20:14
essentially a solution and all in a
20:17
funny way to the that voting problem I
20:21
mentioned a few minutes ago where you
20:23
can't really have some practice I have
20:25
majority votes because we're not sure
20:28
who the participants are or how many
20:30
there are because people may sort of
20:32
create fake computers fake IP addresses
20:35
whatever it will here you have to use
20:39
CPU time which is a sort of real
20:41
resource that cannot be faked in order
20:44
to contribute a new block and that means
20:47
that um you know while it's not really a
20:50
voting scheme the what it's essentially
20:53
doing is the new block gets to come from
20:57
a reactively random choice over the
21:01
different computers that are involved in
21:03
in mining so this scheme is it's a sort
21:08
of a random sort of cryptographically
21:10
reasonably strong random selection
21:12
process for who gets to choose the next
21:15
block and so if there's a small number
21:17
of attackers they're highly unlikely to
21:19
be selected by this process in order to
21:23
contribute the next block now what that
21:25
means is that if most of the
21:26
participants or most of the CPU power in
21:28
the system is controlled by non
21:31
malicious people then most of the new
21:34
blocks will be found by non malicious
21:35
people and that's not an immediate
21:37
solution to double spending but we'll
21:39
see that it that it's the key to the
21:44
double spending defense okay
21:52
all right so let's go back to our
21:54
example we have a blockchain that maybe
21:59
looks like we currently block five
22:02
o'clock fine has been published to
22:06
everybody the mmm them all the peers are
22:11
working on mining a potential block six
22:14
and we don't know what's going to be yet
22:15
because because the miners are still
22:21
working on finding about knots but you
22:23
know we know that it has a bunch of
22:24
transactions in it well if at this point
22:26
why broadcasts you know say it's payment
22:30
to Z well the the miner is already
22:33
working on this block so wise new
22:35
transaction and even if it sends it out
22:37
so now probably not going to be
22:38
incorporated in the block has been
22:40
currently mind but all the miners will
22:42
kind of keep this new transaction and a
22:44
buffer on the side and when one of them
22:46
does find a new block for block 6 then
22:51
wise transaction will be incorporated
22:53
into the attempts to mine block seven as
22:59
soon as somebody does mind box seven
23:01
this Y arrow Z will actually be really
23:04
in the blockchain alright so so one
23:14
question is could there be two different
23:17
successors to walk six could there be
23:20
sort of a block seven and a block seven
23:23
prime right what prevents this structure
23:31
from arising and of course the reason
23:33
why we're interested in this is that if
23:35
the structure could arise then
23:39
then these two maybe seven prime B seven
23:43
double prime then these two different b7
23:46
s two different successive successors to
23:48
b6 might have different transfers from Y
23:51
and so if you were aware of just b7
23:54
prime you'd think why paid it's Bitcoin
23:57
to see if you were we're only a b7 prime
23:59
prime you this would click a totally
24:01
legitimate payment from wide acute my
24:05
question is can there be two different
24:07
successors to a block it turns out the
24:11
answer is yes and it's actually does
24:14
happen reasonably frequently and the
24:17
reason is that there's you know
24:18
thousands of peers out there Mining away
24:22
trying to find the successors to block
24:24
six and they're likely mining it's you
24:27
know trying to produce somewhat
24:29
different blocks with different sets of
24:30
transactions in them so it's easy to
24:32
imagine a situation in which some of the
24:34
peers you know they happen to see just
24:37
because of the way the transactions move
24:38
through the network they happen to see
24:40
why it's transferred to Z first and
24:42
incorporated in to block their mining
24:44
and other peers you know for sort of the
24:46
same successors but the their version of
24:49
the block their mining as a successor to
24:51
six just happen to have seen this
24:53
transaction first and included that in
24:54
the block so we can easily get different
24:57
miners trying to work in a way trying to
24:59
produce different successors to be six
25:01
if two of them happen to find a nonce
25:03
that satisfies the leading zeros in the
25:06
hash rule at the same time that means we
25:10
have two different blocks to tumor
25:11
totally valid blocks produced at the
25:13
same time and they're both going to send
25:17
those blocks out into the network and
25:18
they'll be seeing that you know on
25:20
roughly the same time by all the other
25:22
peers so it could easily be the case
25:25
that two different two quite different
25:29
successors to block six may arise and
25:34
it's called the fork
25:40
and so we're very interested in what
25:43
happens to Forks because this can and
25:46
does arise well the most immediate rule
25:49
is that as soon as any peer sees a
25:53
successor oh you know all the peers are
25:56
trying to mine a successor to block six
25:59
as soon as than ever any of them any of
26:02
them sees a new successor block be
26:05
flooded from some peer that did
26:06
successfully mine
26:08
it'll stop working on six and
26:10
immediately switch to trying to work on
26:12
a successor from b737 so initially every
26:16
peer as soon as it sees a successor
26:19
block switches to mining a successor for
26:22
that successor block so in this
26:24
situation some of the peers will see b7
26:26
Prime first and start working on a
26:28
successor to that then other peers will
26:30
start mine will see b7 prime prime for
26:33
it's just depending on you know what
26:35
they happen to see first if the if these
26:37
two are mined at the same time and
26:39
they'll start working on a successor to
26:40
b7 prime prime so now we got some of the
26:43
peers working on sort of extending this
26:45
fork in the blockchain and the other
26:48
peers working on extending this fork in
26:51
the blockchain however another critical
26:59
rule is that if a if somebody's mining
27:08
away on this trying to make one of these
27:11
blocks and it sees a new block for a
27:14
different fork that's longer then
27:18
anybody working on extending this fork
27:21
will switch to extending this longer
27:23
fork so that's a rule in the software
27:27
that everybody is supposed to favor the
27:30
longest chain so at least initially if
27:33
we have some of the peers mining a way
27:35
on one fork and the other and there's
27:38
the same length and others mining on the
27:40
other fork it turns out the variance in
27:42
how long it takes to produce a valid
27:45
knots is pretty high
27:47
so it's even if there's equal number of
27:50
peers mining both Forks it's highly
27:53
likely that one of them will find a
27:56
successor significantly before the other
27:58
and so this successor will be flooded to
28:00
a bunch of nodes appears that were
28:02
working on this successor and they'll
28:04
all switch to the longer Fork and so
28:07
that means that there's sort of an
28:09
asymmetry here that causes us a slight
28:16
you know with if this Fork itza gets
28:19
extended by the minor slightly before
28:21
this fork then that'll contract miners
28:24
over onto this fork it'll be more and
28:26
more miners mining on this Fork and so
28:29
the new blocks will be found more and
28:32
more rapidly on the winning fork so
28:34
there's a tendency sort of reinforced
28:36
success that's the longer fork gets
28:39
longer and pretty soon once all the
28:42
miners have heard about this longer fork
28:43
nobody will be left the mining on this
28:44
fork everybody will ignore it and
28:46
everybody will only treat this longest
28:49
fork as the real as the real chain okay
28:55
so this is it's highly likely that one
29:00
of the there's a fork that one of the
29:02
two Forks will see an x-block first will
29:06
be longer everybody all the peers will
29:08
switch to mining on it and that
29:10
everybody will rapidly agree that one of
29:12
the other is the longest fork of course
29:15
the transactions on the abandoned fork
29:19
you know usually most of the trend
29:21
usually these two competing blogs have
29:24
you know pretty much pretty similar set
29:26
of transactions but there may well be
29:28
transact a few transactions here that
29:30
were not there and certainly if
29:31
somebody's trying that will spend or but
29:34
if there are transactions in the
29:35
abandoned fork that didn't happen also
29:37
to be in the winning fork then these
29:39
transactions they just go away there's
29:42
no attempt in the sort of blockchain
29:44
system itself to try to carry over these
29:47
transactions now with it or there's no
29:50
attempt to kind of directly merge the
29:52
two forks now in fact you know if you
29:54
don't see your transaction show up you
29:56
maybe issue it
29:58
and you know because the blockchain is
30:00
public it'll become apparent that your
30:02
transaction needs to be reassured
30:04
because it wasn't incorporated more in
30:05
the winning fork however it is also the
30:10
case that for a brief period of time
30:13
both of these transactions were in the
30:17
blockchain right so for a brief period
30:21
of time there was a double spending of
30:23
wise coin in the blockchain and that you
30:28
know that's like a little bit of a
30:29
dangerous situation in fact you know
30:30
it's an extremely dangerous situation
30:32
right since the whole point was to avoid
30:34
block chains right until one of these
30:35
two chains got longer now it was totally
30:38
unclear which of these two chains to
30:40
believe and then these some of the peers
30:42
may only know about one of them or the
30:44
other of them so this raises a sort of
30:47
unhappy question about how Q or Z you
30:51
know what procedure should they use to
30:53
be sure that they've actually been paid
30:54
right apparently it's not enough for Z
30:58
to say well as soon as the transaction
31:01
appears in the blockchain then I'm sure
31:02
I didn't paint because that's not true
31:04
right maybe the maybe this bar chain
31:07
would end up being a shorter one and the
31:09
wipies Q blockchain will win similarly P
31:12
you can't just look at oh you know my
31:14
transaction showed up in this block and
31:18
the blockchain therefore it's a valid
31:19
transaction because it may end up being
31:21
abandoned due to being on a shorter fork
31:22
and so this is the reason for the rule
31:24
in that people who care don't really
31:28
believe in transactions until there's a
31:30
couple of blocks after them in the
31:33
blockchain and as a as the longer chain
31:37
gets longer and longer or as what you
31:39
think is the longer chain gets longer
31:41
and longer the chances that there might
31:43
be some other chain that will become
31:46
longer in it longer than it could
31:48
vanishingly small because if you're on a
31:50
slightly longer chain that's going to
31:52
attract miners to mining on it so no
31:55
other chain can grow very rapidly and of
31:58
course the you know the rate in which a
31:59
chain a particular fork can grow is
32:03
proportional to the number of peers that
32:06
are mining on that chain
32:10
all right so this is this is the
32:14
mechanism that prevents with it makes it
32:18
so that if Y sends out two conflicting
32:21
transaction that's at the same time even
32:24
though there can be a brief double spend
32:25
if there's a fork it will rapidly be
32:28
only one or the other of the two
32:30
transactions will be in the longest
32:32
chain and so one of them will win in the
32:34
sort of official chain now and you know
32:39
indeed if if this second transaction
32:41
shows up is sent to peers later on after
32:44
the Y transfer disease in the chain then
32:47
all the peers will ignore trend newly
32:52
arriving transactions that for coins
32:55
that have already been spent in a
32:57
transaction on the chain on the fork
32:59
that they're mining for so why can't you
33:02
know send out this transaction again
33:04
after the first transactions shows up in
33:07
the chain in the blockchain okay okay so
33:15
you know there's some other attacks you
33:17
might wonder about one question is
33:20
whether you know let's suppose that this
33:25
is the this is the chain if Y is
33:30
colluding with some peers and this is
33:33
the official b7 and we have a b8 etc you
33:36
know
33:36
supposing why isn't League with some of
33:38
the peers could appear take this block
33:41
seven it's now you know in the middle of
33:43
the chain and change it to produce just
33:47
a different block that doesn't have this
33:50
transaction in it and just sort of
33:52
substitute this new block for the old
33:56
block seven and sort of pretend that
33:58
block e refers to it and now block this
34:00
new block seven doesn't have a
34:03
transaction and so that sort of very
34:05
straightforward changing of a single
34:07
block doesn't work and the reason is
34:10
that these arrows here are really really
34:13
means that there's a cryptographic hash
34:15
and blog ate that
34:17
is the hash of the block seven it refers
34:19
to and so this hashing blockade you know
34:23
for for a block seven that already
34:25
exists this hashman block eight is a
34:26
hash of the original block seven if
34:29
someone changes this content it's gonna
34:31
have a different hash and so this
34:33
blockade hash if you try to pawn off
34:37
this modified block on somebody who
34:38
knows about block eight they're gonna
34:39
say we didn't have our keys you know
34:41
hash doesn't hash to the same no block
34:43
this block seven prime doesn't hash to
34:45
the same value that's embedded in Block
34:47
E so you can't trick anybody who knows
34:50
about subsequent blocks into accepting a
34:52
modified intermediate block alright
34:55
question
34:55
I see why is a Q store by his coffee it
35:00
shows up in one of the blocks
35:03
oh I see ok so this is a let me just
35:08
back up a little bit so I think the
35:10
scenario we have is that you know there
35:12
was a blockchain and then a brief fork
35:16
and in that brief fork why pay the same
35:20
coin to two different two different
35:28
parties and let's say this is block 7
35:33
prime prime and it's block 7 that wins
35:37
and is on the main chain and block 7
35:40
prime prime is it's just forgotten and
35:43
ignored and the question is jeez you
35:45
know for briefly at least Q saw this
35:48
transaction show up in the chain and
35:49
gave the cup of coffee to why and then
35:51
why I left the store but then you know
35:53
this part of the chain is discarded and
35:55
Q is left with no money they've given
35:57
away some coffee but they did not get
35:59
paid and that just is what happens in
36:01
this scenario all right if Q was willing
36:05
to handle with a cup of coffee after
36:07
seeing the transaction in just the last
36:10
block in the blockchain then they'd risk
36:12
this scenario and there's nothing they
36:13
can do about it and they can't get the
36:15
money back I mean unless you run down
36:17
the street catch up with the person and
36:20
take the cup of coffee away and that is
36:23
the reason why for high-value
36:25
transactions your Starbucks trolley
36:27
doesn't care very much right that cup of
36:29
coffee really only cost like you know 50
36:32
cents to make like if they occasionally
36:33
you know these Forks don't happen that
36:35
often they occasionally lose a cup of
36:37
coffee well they can probably willing to
36:40
deal with that but if if why was buying
36:44
a car from Q for you know $20,000
36:47
Bitcoin thank you probably would rather
36:49
not let Y walk off with this level of
36:53
assurance that being paid and that's the
36:56
reason why if you care you'll wait until
36:59
multiple blocks show up after the block
37:02
in which in which your transaction was
37:05
in so Z won't actually him if it's a
37:08
high-value transactions he won't hand
37:10
over the goods until there's at least
37:12
some number five six blocks showing up
37:15
after the block
37:17
Action Shooting open and it's very
37:22
unlikely that a a fork could be extended
37:26
at five or six times like over a period
37:28
of an hour now ken block's show up only
37:30
every ten minutes and then turn out to
37:32
be the shortest not the longest chain
37:35
because that means that there was some
37:36
other fork that was extending faster and
37:43
the only way some other before could
37:44
extend faster is that if a majority of
37:46
the cpu power was working on it and
37:47
we're assuming that a majority the cpu
37:49
power is islam malicious and is
37:52
therefore switching to the current
37:55
longest chain all right so this is you
38:01
have to be if you're doing large value
38:03
transactions you have to be careful and
38:05
wait till a chain goes long and after
38:07
your transaction shows up okay so okay
38:15
so I explained why you can't simply
38:17
modify a block in the middle of the
38:19
chain there's a related question which
38:22
is supposing there's an existing
38:24
blockchain you know that's something
38:29
that long and your transaction Y arrow
38:35
transaction why does he shows up here in
38:37
the blockchain and you want to get rid
38:41
you want to hide that transaction now
38:42
somehow make it so it doesn't exist well
38:45
gosh why don't you produce a new sort of
38:47
alternate chain that you know is mostly
38:52
identical to the main the real chain but
38:55
it's longer and just happens to omit Y
39:00
is transferred to Z and instead includes
39:03
Y is transferred to Q and if you do the
39:05
mining correctly for this and the hashes
39:07
work out your chains longer and it just
39:09
will be accepted under the rules of
39:10
Bitcoin which which everybody supposed
39:13
to switch to the longest chain so how
39:15
come you can't do this
39:20
and this you know this would also allow
39:22
you to double spend by essentially
39:24
unspent in a previous spent quantity and
39:26
my earlier comment about oh you're
39:28
supposed to wait you know zis was to
39:30
wait until the blockchain gets extended
39:32
you know this is now a way to defeat Z
39:36
waiting for the blockchain to extend it
39:38
so we're really because serious trouble
39:41
if you could make this work okay so and
39:46
somewhat well the answer is yes this can
39:48
be made to work and here's how to do it
39:52
you know the main blockchain is being
39:54
extended by the non malicious
39:56
participants at some rate right they
39:59
have enough CPU power to you know
40:00
produce a new block every 10 minutes if
40:02
you're the attacker and you have more
40:04
CPU power than the entire non-malicious
40:07
set appears then you're going to be able
40:10
to generate walks faster than the real
40:13
chain so your block makes your you know
40:15
chain may start out shorter and I may
40:17
take you a while to generate each block
40:19
but you know maybe you can generate two
40:20
blocks every ten minutes whereas the
40:22
main chain is only capable of generating
40:25
one block every ten minutes so that
40:26
means that for a while you'll have
40:28
caught up and exceeded the length of the
40:30
main chain the main fork and by the
40:34
rules of Bitcoin everyone you
40:36
non-malicious totally correct Bitcoin
40:39
peers they'll all switch to your longer
40:41
chain and that means they'll all
40:42
effectively forget this transaction and
40:45
except this other transaction this
40:47
second spend of the same coin so if
40:49
you're an attacker and you have more CPU
40:51
power than the entire rest of the
40:53
network
40:53
you can produce this chain and it means
40:56
you can double spend and you know that's
41:02
certainly you know something to think
41:05
about but the reason why you might hope
41:11
more be sort of somewhat confident that
41:14
it couldn't arise is that in a big
41:16
system with lots of participants it
41:18
might be very hard to assemble more CPU
41:21
power than the entire rest of the system
41:24
so once the buns Bitcoin grew big you
41:28
know people were somewhat confident that
41:31
the main sort of non-malicious system
41:33
had enough cpu power that it would be
41:35
expensive for an attacker to assemble
41:38
more CPU power than the rest of the
41:40
system of course for new
41:43
cryptocurrencies that don't yet have
41:45
very large mining operations going
41:48
they're actually easy to shoot down it's
41:51
easy for a new cryptocurrency like
41:52
Bitcoin it's easy for an attacker you
41:54
know for whatever reason to put it out
41:56
of business by getting more CPU power
41:59
but for a big system like Bitcoin it's
42:01
somewhat difficult now that said the
42:05
people who've looked into tried to
42:07
figure out who controls mining CPU power
42:13
and Bitcoin suspect that the biggest
42:17
players have fractions of the total that
42:22
are not that far from 50% and that
42:25
certainly if you know two or three of
42:27
the largest mining operations combined
42:30
forces that they would have a majority
42:33
of the mining power in Bitcoin and could
42:36
produce alternate Forks like this so
42:38
that's a somewhat troubling development
42:45
you know whether there'd be motivated to
42:47
do something bad especially since sort
42:49
of everything that's done in Bitcoin is
42:51
public that's what people would really
42:53
notice that oh gosh that was a long
42:55
chain and then we switch to a chain that
42:58
started way far back boy would people
43:00
ever notice that and that would you know
43:04
destroy confidence in Bitcoin and may
43:06
undermine anything that the malicious
43:08
parties were hoping to achieve
43:10
so since you know it is very expensive
43:11
actually you know the big players in
43:13
mining in Bitcoin I spent a huge amount
43:15
of money to buy the mining hardware that
43:19
they owned and so they probably wouldn't
43:21
want to undermine people's trust in
43:22
Bitcoin because that would destroy the
43:25
value of their vast collections partner
43:29
all right any questions about the
43:31
machinery here all right so I
43:40
questions that I can ask an answer one
43:45
question is that the ten minutes between
43:48
blocks is actually a serious annoyance
43:50
it means that if I want to buy something
43:52
it takes up to 10 minutes before the
43:55
transaction shows up in the blockchain
43:57
at all
43:57
even even in the first block and you
44:02
know either I have to wait around for 10
44:04
minutes to get my cup of coffee or the
44:06
store owner has to give me my cup of
44:07
coffee before the trans before the
44:10
transactions in the blockchain at all
44:11
thus having to trust me so why can't we
44:14
make the 10 minutes much shorter and you
44:21
know actually the 10 minutes probably
44:23
could be made shorter the practical
44:24
reasons why it isn't shorter is that it
44:28
actually it takes a while for new box to
44:30
be flooded over the system right after a
44:33
miner finds the next block it has to be
44:35
sent thousands of peers Bitcoin over
44:38
possibly slow network connections and it
44:41
may take quite a while before that block
44:43
is known to all the other peers and that
44:45
means that there's some period of time
44:47
in which other peers are mining on
44:50
blocks or wasting their time mining
44:54
blocks that are I've been superseded by
44:58
a block that hasn't yet beached them and
45:02
basically the fraction of time you spend
45:07
mining wasting of trying mining blocks
45:09
that have been superseded is related to
45:11
how long it takes to mine each block
45:15
compared to how long it takes to flood
45:17
the block and so if you make the inter
45:19
block interval shorter and shorter then
45:23
it starts to it gets small enough that
45:25
it approaches the amount of time it
45:26
takes the flood new blocks and that
45:29
would cause most piers to waste most of
45:32
their mining effort and since the miners
45:34
are actually making money making Bitcoin
45:36
by mining because there's a little
45:37
reward to the successful miner of each
45:39
block the miners are very uninterested
45:42
in wasting resources mining for blocks
45:47
that are have been superseded and so
45:51
they're very uninterested in
45:53
this 10-minutes be much shorter than it
45:55
it's now and you know that's a
45:57
significant constraint so there's a
46:02
question what prevents why from double
46:04
spending much in a much later block when
46:07
piers might have forgotten about the
46:09
first transaction and so you know the
46:11
question is oh you know in a very early
46:14
block why transferred according to Z and
46:17
then there are thousand blocks later Y
46:20
tries to transfer the same coin to Q you
46:24
know like a year later or something and
46:26
the answer to how this plays out is that
46:29
all the peers remember this forever
46:32
they absolutely remember every unspent
46:36
transaction forever and that means that
46:45
actually that can't be the first
46:47
I think nominally to tell you the truth
46:51
I don't understand all the ins and outs
46:52
of this but one way the most
46:54
straightforward way to solve this
46:55
problem is for all peers to remember
46:57
every transaction forever and every
46:59
incoming transaction they check to make
47:02
sure that the coin hasn't been spent yet
47:05
they just the course create a database
47:08
or index or something but allows them to
47:11
essentially check every record to see if
47:13
this coin has already been spent and I
47:17
think you can although I don't fully
47:19
understand this I think peers can
47:21
discard a lot of though a lot of this
47:25
information by only remembering
47:27
information about unspent transactions
47:30
so they keep a database of unspent
47:32
transactions but it doesn't include
47:35
spent coins and if a new transactions
47:38
coin isn't in the database of unspent
47:40
transactions then it's just ignored but
47:43
this you know this database has to be
47:45
every pair has to keep this database
47:47
forever so you know just of course this
47:52
is a in a way a very expensive system
47:54
because what we're talking about is you
47:56
know maintaining a record of every
47:58
transaction essentially forever and you
48:01
know if you think about how many
48:01
transactions there are per second or per
48:04
year on earth
48:05
it's a vast number and so people really
48:09
were serious about using Bitcoin they
48:11
used it for everything in the way they
48:12
use cash now it would you know it would
48:16
be an enormous system and there would be
48:18
enormous performance streams on the
48:20
system and indeed Bitcoin is not really
48:22
capable of supporting every transaction
48:27
you couldn't run the entire financial
48:30
system of the world on Bitcoin as it
48:32
exists today and there's a bunch of
48:34
there's a bunch of limits you know one
48:38
limit is that the full Bitcoin database
48:40
already consumes a couple hundred
48:41
gigabytes yeah that's actually not so
48:43
bad because you can fit it on a disk but
48:46
if it was a thousand times larger it
48:48
would start to be a serious problem to
48:49
even store it let alone search for stuff
48:51
in it the most immediate problem
48:56
and we it turns out that processing that
48:57
transactions it's not terribly expensive
48:59
because for the peers it's mostly about
49:01
hashing and these cryptographic hashes
49:03
are pretty quick but the sort of most
49:07
current you know ugly restriction is
49:11
that these block cuz there's a limit to
49:14
how big these blocks can be these blocks
49:16
can only be a couple megabytes in size
49:18
and new blocks appear only every ten
49:22
minutes and so that means you only get
49:25
you know less than a megabyte of new
49:27
transactions per minute each transaction
49:30
the sort of Val you know is very way
49:35
various ways of abbreviating them but
49:37
you know each transaction is at least
49:39
dozens or a hundred bytes and that means
49:42
that the system can really only because
49:45
of this block size limit and the ten
49:46
minute limit the system can only process
49:49
sort of thousands or tens of thousands
49:52
of transactions well I'm not sure I can
49:57
divide properly but it's not nearly
49:58
enough to run the current way that
50:03
Bitcoin set up is not nearly
50:05
high-capacity enough to run the world
50:07
all the world's financial transactions
50:09
are and so you know people change it it
50:12
evolves but it's not really fast enough
50:18
for everything of course nobody's really
50:20
using it for commerce it's mostly used
50:22
for speculation as far as anyone can
50:24
tell so it's not yet a problem but from
50:27
a design point that there needs to be
50:29
some things fixed okay so I mentioned
50:35
before that the Bitcoin software adjusts
50:38
the hardness of finding nonces that is
50:40
the number of required leading zeros in
50:42
the block hash adjusts that dynamically
50:45
to cause there to be ten minutes for
50:49
block one thing that has to be the case
50:54
though is that all the participants have
50:56
to agree on the required number of
50:58
leading zeros they actually all have to
51:00
agree on the hardness of finding a knots
51:02
and so if one peer sort of looks at the
51:06
rate at which blocks have been produced
51:07
and
51:09
besides that it's too slow and it should
51:12
make the require fewer leading zeros but
51:15
the other peers haven't made the same
51:17
decision then that first piers will be
51:20
generating blocks that are rejected by
51:22
the other peers because all the peers
51:24
demand what they think is the correct
51:26
number of leading zeros in the hash so
51:31
there has to be agreement on on the
51:35
hardness of finding a nots
51:36
that the the peers have to agree exactly
51:39
and what the current hardness is
51:40
otherwise they'll reject each other's
51:42
blocks so how do they reach that
51:44
agreement it turns out actually to be
51:48
totally straightforward they all are
51:52
looking at the same blockchain after all
51:54
that was the whole point is that you
51:56
know except for temporary Forks there's
51:58
just one blockchain everybody hasn't a
51:59
copy of the exact same bits in the
52:02
blockchain and so the Bitcoin just
52:05
defines a deterministic function that
52:09
takes the current blockchain as its
52:12
argument and uses that to
52:13
deterministically produce the current
52:16
hardness of finding a nonce and the way
52:19
it does that is basically it looks at
52:21
the timestamps in the blocks to decide
52:25
how fast the recent blocks have been
52:27
produced but since everybody's looking
52:28
at the same blocks in the same time
52:30
stamps and is running the same function
52:32
to adjust the hardness they all come to
52:35
exactly the same conclusion about what
52:38
the hardness ought to be for for each
52:40
successive block in the blockchain so
52:42
there's a kind of interesting agreement
52:45
that's being enforced there because they
52:46
all see the identical same laws all
52:51
right
52:52
another interesting question is that one
52:54
of the motivations that some people have
52:56
for being interested in new
52:58
cryptocurrencies is that they might be
53:00
more anonymous than credit cards and
53:02
indeed credit cards are deeply
53:03
non-anonymous since the credit card
53:06
company knows exactly what you're up to
53:08
I keeps a record of it whereas Bitcoin
53:11
at least on the face of it you know
53:13
Bitcoin there was nothing about a
53:14
Bitcoin transaction that say had my name
53:17
on it
53:18
now you might think well each Bitcoin
53:20
transaction has my public key in it
53:22
man that's true if I don't change my
53:24
public key and I always use the same
53:26
public key then once somebody figures
53:29
out my public key is just relatively
53:31
easy since whenever I pay somebody they
53:34
they get to know my public key then
53:36
people can track my activities by
53:38
looking for my public key or my
53:39
signature in the Bitcoin lock and it's a
53:43
public log so anybody can look now
53:45
people everybody who cares and I think
53:49
most Bitcoin wallets offer actually
53:51
generates fresh public keys for each
53:53
transaction I'm said anytime if somebody
53:56
wants to pay me money my wallet will
53:58
generate a new never used before public
54:00
private key pair
54:01
remember the private key then give the
54:03
public key to the person who wants to
54:05
send me money and that makes the
54:07
tracking harder but it turns out that if
54:14
you're up against determined sleuth
54:17
there's you know there's enough clues if
54:20
you make transactions often enough since
54:25
the transactions are often tied to your
54:26
real identity like if you buy something
54:28
from Amazon with Bitcoin yeah maybe the
54:31
Bitcoin transaction it's not clear it's
54:33
you but it probably needs to be shipped
54:34
to you by FedEx to your home address and
54:36
that's a little piece of identifying
54:38
information there and that will allow
54:41
somebody to figure out it was you who
54:42
spent that money and they'll be able to
54:44
straight track backwards to see where
54:46
that money came from to get another clue
54:48
about who you are and what you're up to
54:50
so in fact against amateurs Bitcoin is
54:57
reasonably anonymous against serious
54:59
adversaries a Bitcoin has turned out not
55:02
to be particularly anonymous okay
55:10
a little bit disappointing from a little
55:12
bit disappointing for people who are
55:14
interested in privacy or doing drug
55:16
deals or financing illegal activity
55:23
alright
55:24
sum up the sort of key idea here is the
55:28
blockchain like a public ledger that
55:31
everybody agrees on and that has every
55:34
transaction on it and all that has a lot
55:36
of problems like with scalability if you
55:39
can make it work it's a great idea
55:41
another sort of key technical problem is
55:43
how to do this without any
55:45
centralization now whether the
55:48
centralization or decentralization of
55:50
valuable property is kind of not really
55:52
a technical question but if you value it
55:55
then it's just really cool and amazing
55:57
but it's possible to have agreement on a
56:00
single log with no central trust and I'm
56:05
using participants many of whom are
56:06
actively malicious and the final key
56:09
idea is that is the idea of mining a
56:13
proof-of-work where it too has problems
56:14
but it's very surprising that a
56:17
technique existed at all that allowed
56:21
agreement in a way that can't be fooled
56:24
by these sort of fake IP address attacks
56:27
that doesn't suffer the same problems
56:29
that voting suffers that was a very
56:31
surprising and interesting development
56:33
all right that's all I have to say the
56:37
actually sent kind of continuing some of
56:40
this line of thought and the next
56:41
lecture which is a sort of different
56:44
kind of decentralized system partially
56:49
built on top of Bitcoin