Why Bitcoin’s base layer can’t be scaled
Tags: Cryptocurrency, Crypto, Bitcoin, Technology

As the Bitcoin community argued throughout much of 2017 about how to scale a network hit by high fees, a group of miners and developers decided to take matters into their own hands by forking BTC and increasing the block size of Bitcoin, creating Bitcoin Cash (BCH).

Why would increasing block size be the right way to scale the Bitcoin system? When more miners join the BTC network, one might think the additional processing power would increase transaction speed — but this isn’t so, as additional miners only increase the network’s security.

In fact, BTC’s transaction processing speed is directly a function of the system’s settings for 1) block size and 2) block creation rate, both of which are community determined.

In the sections below, we’ll explore why transaction speed can’t be scaled using these levers without increasing vulnerability to double-spend attacks (although there are other concerns, like the increased centralization risks and node requirements posed by larger block sizes).

Along the way we’ll try to cover a few relevant Bitcoin basics, but there should hopefully be many other great sources, including the white paper, which have that covered.

One of Bitcoin’s core security assumptions is limited network delays

In Bitcoin’s white paper, a few fundamental assumptions ensure the network’s security:

Users each keep a copy of the “blockchain”, and updates are handled for “honest” users by always updating to the “longest chain” they are aware

Miners solve “proof-of-work” puzzles to add blocks onto existing chains, and block additions are handled for honest miners by always adding to the “longest chain” they are aware of

When there are limited network delays and honest participants control >50% of the network’s total computational power, the longest chain will be controlled by honest participants and will (with very high probability) grow faster than attackers’ alternate chains

In real-world conditions when there are at least some network delays, we’ll discuss how increasingly large block sizes and faster block creation rates lead to more “forking”, which decrease the security of the network.

Security (in this context) means preventing double spend attacks

When security is discussed in the context of Bitcoin, we are referring to the ability to prevent double spend attacks.

There are two stages to getting a transaction completed on the Bitcoin network — A) User A needs to access their Bitcoin wallet to declare they are sending money to User B, and B) the network acknowledges this transaction and adds it to the permanent record on the longest chain. While security for Step A is really about wallet and wallet password security, security for Step B is about making sure previously “valid” transactions aren’t rolled back in “double spend” attacks.

What is a double spend attack? It involves an attacker first issuing a transaction on the current longest chain, then using their computing power to create an alternate longer chain that does not include that original transaction. Note that for Bitcoin, the longest chain is always the “truth” — honest users pull from it to update their own records, and honest miners add to the longest chain when they find new blocks.

Let’s say Bob sends Jim 1 BTC for a pizza. After this transaction is confirmed on the longest currently available chain in block 10, Jim gives Bob his Pizza. However, if Bob wants to cheat his system, he can start from block 9 and mine a new block 10 and block 11 which not only doesn’t include his payment to Jim, but uses the same 1 BTC in another payment to pay for chicken wings.

Since Bob has created a new longest chain that excludes his payment to Jim, Bob has now spent the same 1 BTC twice (“double spend”) for BOTH a pizza and chicken wings, while Jim has been cheated out of his payment money and is missing a pizza.

Bitcoin’s block creation rate and block size can be changed easily…

When we discuss Bitcoin scalability, it’s important to note that both the “block” creation rate, which determines the confirmation speed of transactions, and the individual block size are determined by the network. Notably adding additional computing power will make the network more secure against attackers, but does not directly result in more transactions being processed.

Since (# of transactions processed / second) = (# of blocks created / second) * (transactions per block), Bitcoin’s scalability is actually something the community can actually set if agreed upon.

So why can’t Bitcoin simply scale by increasing block creation rate and block size (e.g. as Bitcoin Cash attempted)?

… but only at the expense of security (decreasing the security threshold)

This is because increasing either of these variables decreases the network’s security threshold.

Security threshold = % of the network’s processing power needed to run a double spend attack

Bitcoin’s core security rests on the idea that if “honest” nodes control >50% of the computing power, they will be able to mine blocks and grow their longest chain faster than any attacker can potentially create an attacking chain.

Let’s run a few basic calculations to see how this might work.

H = growth rate of main chain (in # of blocks/second), controlled by honest participants

D = growth rate of attacker’s chain

Z = amount of computing power, on average, needed to successfully create a block

If H > D, then the honest longest chain will grow fast enough to be secure from double spends.

Under good network conditions, if the total computing power of the network is C, the fraction of computing power controlled by honest nodes is h, then say (for simplicity) H = C*h/Z. If the fraction of computing power controlled by dishonest attackers is d, then D = C*d/Z.

With ideal network conditions, an attack will succeed if D>H, or d > h. Since all nodes are either honest or dishonest, d+h = 1, and the security threshold is 50%.

Higher network delays means the honest longest chain grows more slowly

Previously, we noted that Bitcoin’s security in it’s original white paper assumes a “synchronous” network, where participants learn of new blocks and the current longest chain instantaneously.

Say there is a blockchain with 5 blocks (Blocks = A, B, C, D, E) — think about two scenarios:

A) Network/internet is fast - miners learn of new blocks and new longest chains quickly, and quickly switch to working on top of new longest chains. Here, a newly discovered block would be F, and would follow right after E.

- miners learn of new blocks and new longest chains quickly, and quickly switch to working on top of new longest chains. Here, a newly discovered block would be F, and would follow right after E. B) Network/internet is slow - miners don’t learn of new blocks quickly. Say Ted’s current blockchain only has 3 blocks, A to C. When he discovers a new block, call it D*, he adds it to his chain (Blocks = A, B, C, D*), only to realize the longest chain is now A to E. Their newly discovered “block” is now wasted and won’t be on the longest chain.

Additionally, (A, B, C, D*) is now a “fork” of (A, B, C, D, E) — it’s shorter than the longest chain, and has a different block in an earlier position.

Effectively when honest computing power is wasted creating blocks on top of old chains that aren’t the longest, the longest chain by honest nodes grows more slowly as computing power is wasted on unused blocks.

So instead of H = C*h/Z, it might be H = ½ * (C*h/z) if half of the blocks are wasted. So now even if honest nodes own 50% of the computing power, the security threshold is only

For an attacker to be able to win:

D > H → C*d/Z > C*h/Z → d > ½*h → d = 1/3

Security threshold = 34%

Therefore when there are network delays, h > d alone doesn’t guarantee security. Indeed, an attacker with only 34% of computing power could succeed in an attack.

Why doesn’t forking affect dishonest attackers? We usually assume dishonest attackers can communicate more easily among their own nodes (e.g. through direct network connections), and always focus their efforts on growing a single chain, therefore wasting fewer blocks.

For more details on this idea, see source DW13 here:

https://eprint.iacr.org/2016/454.pdf

“Indeed, Decker and Wattenhofer [DW13] already experimentally observed that increasing the networks delays in Nakamoto’s protocol leads to increased forks, and they noted (through heuristic calculations) that an attacker could use these delays to violate consistency with an attack that requires less than 50% of the mining power.”

How do block size and block creation rate affect “forking”?

Increasing the block size makes it slower for new blocks to be communicated throughout the network. This is similar to the effect of slowing down network speeds, in that new blocks and longest chains take longer to be propagated across the network, increasing the frequency of forks.

The impact of “block creation rate” is also similar — the more quickly new blocks are being created, the more often the longest chain is growing, and the more often nodes will find themselves wasting “blocks” by working on top of outdated, shorter chains.

Final thoughts

While adding additional mining power to the network makes Bitcoin more secure, couldn’t you then increase block size or creation rate to increase transactions processed, while still keeping security constant?

This might work in theory, but probably isn’t the long-term solution for Bitcoin, since Bitcoin would need to scale by orders of magnitude more before it became competitive with other centralized solutions (like Visa), assuming the goal is to become a method for everyday payments.

In the meantime, there’s always the Lightning network for users to hold out hope for.