So finally we'll talk about some built in
limitations to the Bitcoin protocol and
why it's challenging to
actually improve them.
There are a lot of hard-coded constants
that are implemented into the Bitcoin
protocol, which were chosen when
Bitcoin was proposed in 2009, before
we really had any idea that it might grow
into this globally important currency.
So the most important limits are probably
the limits on the average time per block.
The size of blocks.
The number of signature
operations in a block and
the divisibility of the currency.
The limitations on the total number
of Bitcoins in existence as well as
the structure of the mining rewards
are very likely to never be changed
because the economic implications
of changing them are too great.
Miners have invested a lot of real-world
resources into becoming miners
assuming that Bitcoin rewards
would take a certain shape and
that the limited supply of Bitcoins
would remain the way its been planned.
So if you change that, that would have
large financial implications for people.
So for that reason the community has
basically agreed that those values,
whether or not they were wisely
chosen we're basically stuck with.
Some other changes you'd like to make seem
like they would make everybody better off,
things about Bitcoin that just weren't
quite properly designed at the beginning.
But are also hard to change.
The main aspect of Bitcoin that
people are worried about, and
would probably like to change if they
had time to design it over again,
are limits that effect
the throughput of this system.
How many transactions can the Bitcoin
network process per second.
So this limitation comes from the hard
coded limit on the size of blocks.
Each block is limited to a million bytes.
And each transaction has to be at least
250 bytes so if you divide through and
the fact that blocks are found every
10 minutes, you're left with about
7 transactions per second which is all
that the Bitcoin network can handle.
And it seems like tweaking those
numbers would be very easy,
it's just one constant in a file
somewhere that you'd have to change.
It would actually be very hard
to change this in practice, for
reasons that will become
clear in a few seconds.
So how does 7 transactions
per second compare?
Well, if you went down to
the offices of Visa and
told them I'm proposing a new
payment system that can handle 7
transactions per second, they would
probably tell you that's terrible, and
then they would laugh and
throw you out the door.
They've been working for
a long time to build a payment network
that goes way bigger than this.
So it's said that Visa handles,
on average,
about 2,000 transactions per
second around the world.
And the busiest time, so
think the Saturday before Christmas when
everybody's out shopping and
swiping a credit card.
The Visa network can handle about
10,000 transactions per second.
And other payment card
networks are similarly big.
You can also look at PayPal,
which is not as big or as old as Visa, but
even PayPal can handle 100 transactions
per second at peak times, so
in order of magnitude more than Bitcoin.
Another limitation that people
are worried about in the long term is
that the cryptography in Bitcoin is fixed.
There's only a couple of hash algorithms
and there's only one signature algorithm
which is Elliptic Curve DSA over
a specific elliptic curve called SECP256.
And there's some concern that over
the lifetime of Bitcoin which people would
like to be for a long time,
this algorithm might be broken.
Cryptographers might come up with a clever
new attack that we haven't foreseen which
makes this an insecure algorithm.
And the same is true
of the hash functions.
Hash functions in the last
decade have actually seen
steady progress in cryptanalysis with
SHA-1 which is included in the Bitcoin
already having some known
cryptographic weaknesses.
So to change this, we would have to extend
the Bitcoin scripting language to support
new cryptographic algorithms.
So what would it look like to make
a change like this, where we just said,
we had a problem in Bitcoin and
we're going to release the new
version of the software.
And everybody is going to have to switch.
This is what we would call
a hard-forking change.
So in practice, it's impossible to
assume that every node would upgrade.
Some nodes in the network would fail
to get the new software, [COUGH] or
fail to get it in time.
And what would be
the implications of that?
Well, let's take a look at a network here
where most of the nodes have upgraded, but
there are a few that haven't.
And now let's say one of
the new nodes says, hey,
I found this nifty great new block.
Maybe it has some new signature
algorithm in one of the transactions
using the new features that
we've added to Bitcoin.
So block 4 has found this and
says, okay I'm going to update and
say that's now the newest block.
So I'm at block index 24,
the rest of the network is at 23.
But I'm going to propagate
that to all of my peers
using the normal block-flooding algorithm.
So node 4 is going to send block 24
out to it's neighbors, nodes 3 and 2.
Node 3 is going to get it and
say great, I got that one.
I'll update my version of the block
chain to have that as the newest block.
Whereas node 2 is going to say,
that's crazy.
You have some operation code
that's disabled or reserved.
I have to reject this block.
I don't understand it, I can't accept it.
And similarly when it gets over to node 6,
node 6 is also going to say,
nope I can't accept that block either.
And now your going to end up in a state
where the new nodes have one picture of
the block chain and the old nodes have
all refused to accept this latest block.
So the new nodes will go off and
work on a version of the block chain,
including this new block
with the new fancy feature.
And the old nodes will all be stuck
on an old version of the block chain.
And unfortunately, they're never going to
catch up because until they upgrade their
software, they'll keep rejecting all of
the blocks that are proposed by the nodes
in the network that have upgraded
to the new version of the protocol.
So the reason it's called a hard fork
is that the block chain will split,
every node in the network will
be on one side of it based on
which version of the protocol it's running
and they'll never join together again.
And this is considered unacceptable by the
community that old nodes would effectively
be cut out of the Bitcoin network if
they don't upgrade their software.
So by contrast there's
an approach called soft forking,
which tries to avoid creating
a permanent fork like this.
The observation is that we can add
new features to the Bitcoin protocol
if they only restrict the set of valid
transactions or the set of valid blocks.
Because we want to avoid
this hard fork situation,
we can try to add new features in a way
that would cause only a soft fork.
So the key to making this happen is
that the new features can only make
validation rules stricter.
They can only limit of
the set of blocks or
the set of transactions
that are considered valid.
So the new nodes in the network will be
enforcing some new tighter set of rules.
So we're relying on enough nodes
switching to the new version
of the protocol that they'll be
able to enforce the new rules.
Knowing that the old nodes wont
be able to enforce the new rules,
because they haven't heard of them yet.
There is a risk here, which is that old
nodes might be mining an invalid block,
because they include some transaction
which used to be valid, but
according to the new, more strict rules,
is not valid anymore.
So that could be bad.
Those nodes could waste a lot of
time mining a block that the new
nodes will reject.
But when they try to announce that new
block, the new nodes will reject it,
the old nodes will at least figure out
that for some reason, even though I don't
understand the reason, the rest of
the network has rejected my new block.
Therefore, I should move on to the version
of the block chain that all of my peers
have and it won't be a hard fork.
They'll have a temporary fork by virtue of
the new block they tried to mine that was
rejected by the network but they'll
recover and get back on to the main chain.
So the classic example of
a change that was made
via soft fork was pay to script hash.
Which we introduced earlier in the section
discussing the scripting language.
So the view of beta script
hash from old nodes and again
pay to script hash was not present in
the first version of the Bitcoin protocol.
They see the script as really simple.
All it's doing is hashing
this one data value and
checking to see if it's equal to
the value specified in the output script.
The old nodes never do that second step
of verification in pay to script hash,
where they then check to see that that
value before being hashed runs as
a valid script.
So what could we possibly
add with a soft fork?
Pay to script hash was successful.
It's also possible that new cryptographic
schemes could be added by a soft fork or
that we could add some extra meta data
in blocks that had some meaning and
the place you'd add this is
in the coin base parameter.
So, today any value is accepted in
the coinbase parameter but we could in
the future say that the coinbase
has to have some specific example.
One idea that's been proposed
is that in each new block
coinbase contains Merkle root of
the entire set of unspent transactions.
It would only result in
a soft fork because old nodes
might mine a block that didn't have the
required new coin base parameter that got
rejected by the network, but
they would catch up and join the main
chain that the network is mining.
Other changes might require a hard fork.
That would be if we wanted to
add new op codes to Bitcoin.
Change the limits on block or
transaction size or do a lot of bug fixes.
So for example the bug I showed earlier
where the multisig instruction pops
an extra value off the stack that
would actually require a hard fork.
And that's the reason why even though it's
an annoying bug that people wish wasn't
there anymore, it's much easier to
just leave the bug in the protocol and
have people work around it, rather than
have a hard fork change to Bitcoin.
So, all of these hard forking changes,
even though they would be nice,
are very unlikely to happen, at least
within the current climate of Bitcoin.
But a lot of these ideas have been
tested out and proved to be successful.
And alternative currencies,
which start over from scratch.
And we'll be talking about those in
a lot more detail in our lecture on all
Altcoins.
So I spent a lot of time
talking about details today.
I know this has been a long lecture
with a lot of technical detail.
Very hard to absorb it all at once so
like I said I would certainly
recommend you can go online and
see some of this stuff and practice see
what blocks and transactions look like.
It took me a couple of times looking at
them before I really had a good sense of
what was going on but I think
the practical examples do really help.
In the next lecture, given all
these mechanics we've introduced,
we're going to look at
the human side of things.
because after all,
human beings aren't Bitcoin nodes, and
you're never going to run a Bitcoin node
in your head, so how do you as a human
actually interact with this network
to get it to be usable as a currency?
How do you find a node to
tell about your transaction?
How do you get Bitcoins in exchange for
cash?
How do you store your Bitcoins?
So all of these questions are crucial for
making a currency that will actually work
for people, as opposed to just software.