Limitations and improvements

Introduction
 Finally, we’ll discuss about some built-in limitations to the Bitcoin protocol,
and why it’s challenging to improve them.
 There are many constraints hard-coded into the Bitcoin protocol, which were
chosen when Bitcoin was proposed in 2009, before anyone really had any idea
that it might grow into a globally-important currency.
 Among them are 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 total number of Bitcoins, and the block reward structure.
 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.
 Continued…
 Miners and investors have made big bets on the system assuming that the
Bitcoin reward structure and the limited supply of Bitcoins will remain the
way it was planned.
 If that changes, it will have large financial implications for people.
 So the community has basically agreed that those aspects, whether or not they
were wisely chosen, will not change.
 There are other changes that would seem to make everybody better off,
because some initial design choices don’t seem quite right with the benefit of
hindsight.
 Chief among these are limits that affect the throughput of the system.
 How many transactions can the Bitcoin network process per second?
 Continued…
 This limitation comes from the hard coded limit on the size of blocks.
 Each block is limited to a megabyte, about a million bytes.
 Each transaction is at least 250 bytes.
 Dividing 1,000,000 by 250, we see that each block has a limit of 4,000
transactions, and given that blocks are found about every 10 minutes, we’re
left with about 7 transactions per second, which is all that the Bitcoin
network can handle.
 It may seem that changing these limits would be a matter of tweaking a
constant in a source code file somewhere.
 However, it’s really hard to effect such a change in practice.
 Continued…
 It’s quite low compared to the throughput of any major credit card
processor.
 Visa’s network is said to handle about 2,000 transactions per second around
the world on average, and capable of handling 10,000 transactions per second
during busy periods.
 Even Paypal, which is newer and smaller than Visa, can handle 100
transactions per second at peak times.
 That’s an order of magnitude more than Bitcoin.
 Another limitation that people are worried about in the long term is that the
choices of cryptographic algorithms in Bitcoin are fixed.
 There are only a couple of hash algorithms available, and only one signature
algorithm, ECDSA, over a specific elliptic curve called secp256k1.
 Continued…
 There’s some concern that over the lifetime of Bitcoin; this algorithm might
be broken.
 Cryptographers might come up with a clever new attack that we haven’t
foreseen which makes the algorithm insecure.
 The same is true of the hash functions; in fact, in the last decade hash
functions have seen steady progress in cryptanalysis.
 SHA-1, which is included in Bitcoin, already has some known
cryptographic weaknesses, albeit not fatal.
 To change this, we would have to extend the Bitcoin scripting language to
support new cryptographic algorithms.
 Changing the protocol
 You might think that this is simple — just release a new version of the software,
and tell all nodes to upgrade.
 In reality this is quite complicated.
 In practice, it’s impossible to assume that every node would upgrade.
 Some nodes in the network would fail to get the new software or fail to get it in
time.
 The implications of having most nodes upgrade while some nodes are running
the old version depends on the nature of the changes in the software.
 We can differentiate between two types of changes: those that would cause a ​
hard fork and those that would cause a ​soft fork.
 Hard forks
 One type of change that we can make introduces new features that were
previously considered invalid.
 That is, the new version of the software would recognize blocks as valid that
the old software would reject.
 Now consider what happens when most nodes have upgraded, but some have
not.
 Soon the longest branch will contain blocks that are considered invalid by
the old nodes.
 So the old nodes will go off and work on a branch of the block chain that
excludes blocks with the new feature.
 Until they upgrade their software, they’ll consider their (shorter) branch to be
the longest valid branch.
 Continued…
 This type of change is called a hard forking change because it makes the block
chain split.
 Every node in the network will be on one or the other side of it based on
which version of the protocol it’s running.
 Of course, the branches will never join together again.
 This is considered unacceptable by the community since old nodes would
effectively be cut out of the Bitcoin network if they don’t upgrade their
software.
 Soft forks
 A
​ second type of change that we can make to Bitcoin is adding features that
make validation rules stricter.
 That is, they restrict the set of valid transactions or the set of valid blocks
such that the old version would accept all of the blocks, whereas the new
version would reject some.
 This type of change is called a soft fork, and it can avoid the permanent split
that a hard fork introduces.
 Consider what happens when we introduce a new version of the software with
a soft forking change.
 The nodes running the new software will be enforcing some new, tighter, set
of rules.
 Provided that the majority of nodes switch over to the new software, these
nodes will be able to enforce the new rules.
 Continued…
 I​ ntroducing a soft fork relies 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 won’t be able to enforce the new rules because they haven’t heard of
them yet.
 There is a risk that old miners might mine invalid blocks because they
include some transactions that are invalid under the new, stricter, rules.
 But the old nodes will at least figure out that some of their blocks are being
rejected, even if they don’t understand the reason.
 This might prompt their operators to upgrade their software.
 Furthermore, if their branch gets overtaken by the new miners, the old miners
switch to it.
 That’s because blocks considered valid by new miners are also considered
valid by old miners.
 Continued…
 T
​ hus, there won’t be a hard fork; instead, there will be many small,
temporary forks.
 The classic example of a change that was made via soft fork is pay-to-script-
hash, which we discussed earlier in this chapter.
 Pay-to-script-hash was not present in the first version of the Bitcoin
protocol.
 This is a soft fork because from the view of the old nodes, a valid pay-to-
script-hash transaction would still verify correctly.
 As interpreted by the old nodes, the script is simple — it hashes one data
value and checks if the hash matches the value specified in the output script.
 Old nodes don’t know to do the (now required) additional step of running that
value itself to see if it is a valid script.
 Continued…
 We rely on new nodes to enforce the new rules, i.e. that the script actually
redeems this transaction.
 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.
 We could also add some extra metadata in the coinbase parameter that had
some meaning.
 Today, any value is accepted in the coinbase parameter.
 But we could, in the future, say that the coinbase has to have some specific
format.
 Continued…
 One idea that’s been proposed is that, in each new block, the coinbase
includes the Merkle root of a tree containing 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 coinbase 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.
 Examples of this are adding new opcodes to Bitcoin, changing the limits on
block or transactions size, or various bug fixes.
 Fixing the bug we discussed earlier, where the MULTISIG instruction pops an
extra value off the stack, would also require a hard fork.
 Continued…
 That explains why, even though it’s an annoying bug, it’s much easier to leave
it in the protocol and have people work around it rather than have a hard-fork
change to Bitcoin.
 Hard forking changes, even though they would be nice, are very unlikely to
happen within the current climate of Bitcoin.
 But many of these ideas have been tested out and proved to be successful in
alternative cryptocurrencies, which start over from scratch.
 At this point, you should be familiar with the technical mechanics of Bitcoin
and how a Bitcoin node operates.
 Continued…
 But, 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
useable as a currency?
 How do you find a node to inform about your transaction?
 How do you get Bitcoins in exchange for cash?
 How do you store your Bitcoins?
 All of these questions are crucial for building a currency that will actually
work for people, as opposed to just software.