How to understand Bitcoin system expansion

One of the most talked-about topics in 2016 when it comes to Bitcoin is the lack of a good plan for future growth and scaling.

I find this odd because anyone relying on any system should at least do some investigation into what kind of growth it can achieve both this year and over the next 5 or more years and whether it can do what we want.

In this post I want to do a survey of what kind of scaling we can expect from Bitcoin, and what we need to do with the system to get more scaling.

Target

The primary reason Bitcoin has value is the promise that in the not too distant future, Bitcoin will be used and seen as useful by millions of people. Any currency is only valuable if enough people use it. Money is only valuable if it can actually be used. If no one uses it to make payments, its value is not realized.

Therefore, the number one goal is to get millions of people using Bitcoin in their daily lives, where "using" is defined as at least one transaction a day. Like any technology, we think this technology will be usable tomorrow, or even this year, because growth takes time, and systems take time to build.

So one of our goals is that 50 million users send a transaction per day using the Bitcoin network . Not today, but in the next 5 years.

Another further goal is that as a home user, they should be able to process Bitcoin blocks at least five times faster than they are created. This means that if a node is offline for an hour, it will take about 20 minutes to catch up to the latest block (processing the backlog and all the new transactions generated while processing the backlog).

Faster is better, but anything less than 5 times the block creation rate is too slow.

Bottom Line

In other words, what is the current theoretical support?

Bitcoin is a system made up of various node software, which has matured after several years of development. But developers are no longer really paying attention to the growth of grassroots users. Therefore, we see competitors such as Bitcoin Classic and Bitcoin Unlimited entering the competition. As usual, competition is good for end users, and we see some promises of future benefits.

But let's look at what kind of transaction load we can support today.

Last week forum.bitcoin.com published a video about download times. Fully verified and checked 7 years, or 420,000 blocks of history (from the first day of Bitcoin). Using mid-range hardware, 75GB of data took 6 hours and 50 minutes to fully verify. Mid-range hardware is not cheap, but it is certainly not top-of-the-line hardware or server hardware. In other words, it is a good baseline system.

Take a closer look at what was done in 6 hours and 50 minutes:

• Every transaction signature has been verified from block height 295,000 to block height 420,000 (a total of 125,000 blocks).

• 75GB of data was downloaded from Bitcoin nodes around the world.

• A UTXO database contains 11 million transactions, creating 40 million unused Bitcoin addresses. (TX setting information can be obtained from RPC calls).

• 125,000 blocks contain 104,847,758 fully verified transactions. That’s 105 million txs.

We know this was all done without tweaking any settings. This is a Classic 1.1.0 node (which performs about the same as Bitcoin Core 0.12.1)

What kind of work is needed?

Let’s take a look and compare our goals to our bottom line. Most people would like software to be as fast as possible, but priorities are important and we should look at which parts need attention.

Our goal is for a single node to be able to process approximately 50 million transactions in 24 hours.

We noticed that at the 6h50 baseline check, our nodes were actually downloading, storing, and checking nearly 105 million transactions. This works out to a download and verification rate of 368 million transactions per day.

This means that our 5-year goal of 50 million transactions per day is not a problem with today’s bandwidth and CPU power. In fact, our baseline system can exceed our goal by a factor of 7.

Today our baseline system can handle 7 times the volume of our next 5 years goal!

Today, each independent Bitcoin node can download, store, and verify 368 million transactions per day, which is many times the amount of Bitcoin currently in use.

How do I understand system expansion?

Typical family spot

There needs to be nodes that fully validate all blocks to make sure everyone is honest. It also gives me peace of mind that if I trust my node, I don't need to trust anyone else. So I foresee that you will get small communities that gather full nodes. You can have your family use it, or just to support the community, your football club or church will set up a community. Individuals will make their mobile wallets have at least one full node that they trust is someone from his community.

This preserves Bitcoin’s greatest asset, you don’t have to trust a bank or a government. It’s common to trust your local church or football club.

Such a node does not need to keep the full history of blocks from the zero-height block. It will use simplification. With today's hardware, it does not mean that it cannot serve the entire history of blocks, but it can definitely easily fetch a month's worth of block history. However, it means that we need to make the software smarter. Let's look at some simplification ideas.

Hard drive capacity is cheap today. At the current block size limit, a 3TB hard drive can store 75 years of Bitcoin history. But what if we start to reach our goal? What kind of hard drive do we need?

The answer is that we don't need anything bigger at all. It's a misconception that because blocks are bigger we need to have a bigger hard drive. We should actually do some streamlining so that everyone doesn't have to invest more in storage space.

The last big thing we need from our nodes is the speed of our internet connection. To achieve our goal, we need to be able to download 50 million transactions per day, with an average transaction size of 300 bytes.

Ideally, if a node is offline for a while, then when it comes back online we want to download blocks 5x faster to make sure the node can "catch up" with the latest blocks. We might also want to add some overhead for other parts. But today 1.39Mbit download speeds are almost ubiquitous. 2GB is 1440 times faster than what we need to achieve in 5 years, and it's achieved today in countries like Japan.

Home nodes have absolutely nothing to worry about, even with the massive Bitcoin growth of ~50 million users per day. Their hardware and internet can cover them without any trouble, especially in ~5 years when more software optimizations may have been created.

Note that we are not relying on laws like Moore's Law here; we do not need hardware technology to grow in order to achieve our goal.

Typical users

Typical users will use mobile phones or hardware wallets. If users use lightweight clients (SPV), they can achieve secure and fast payments, and the actual requirements for hardware are really low.

Current wallets still need some work though. They are generally pretty greedy in terms of using the network to update the state of the wallet. While useful, there are many situations where this is not necessary, such as when I am abroad and data roaming is very expensive.

No network communication is required before a payment transaction can be created. Only the actual payment itself needs to be transferred to the Bitcoin network.

Typical users use their mobile phones to operate, and when it comes to on-chain expansion, these users hardly need to do anything.

Although the usability of thin clients and related topics does need a lot of work.

Typical mining nodes

Miners need a full node. In this context, “full” means that it verifies all transactions. In addition to meeting the needs of a home node, miners also need to quickly connect to other miners and quickly broadcast blocks to other miners.

Today, most bandwidth and hard drive capacities and CPU speeds are large enough for a typical home node to be part of a network.

Additionally, miners create blocks using their nodes. This means they need to process a pool of unconfirmed transactions and then create a new block. There are some optimizations already in place in this process, but more can be done. For example, before the block is returned, the newly created block chain is checked for validity using the getblocktemplate RPC call. This check takes quite a lot of time and a simple solution would beto decouple the returning of the block and the validation so the miner can start mining optimistically over the check passing (it should pass in 100% of the cases anyway).

As blocks get bigger, more data is returned, and the system currently uses JSON, which is pretty much the worst type of data container for large binary blobs of data. Replacing the RPC interface with something simpler that just changes the communication format to binary is relatively easy to do (probably a month-long project) and probably wouldn't cause miners to end up waiting too long on interface delays.

In our baseline node, we explained that a brand new node would take 7 hours to fully sync from scratch. If we scale the blocks to larger sizes, this will not be the case. It will take a lot of time to do the initial sync. However, miners need fully synced nodes. Bitcoin Classic has made a big change that will significantly reduce validation time. It introduced dynamic checkpoints which allow the node to skipvalidation of transaction data by assuming that about a week's worth of blockswill not be built on top of double-spend data. This will allow a node syncing from scratch to remove millions of transaction validations.

Another suggestion for future Bitcoin clients for miners is that a new node could be pointed to a known and trusted node. The new node would receive the UTXO and all other details needed to get up and running quickly from this trusted node. This means that within 10 minutes, a new node could be running after downloading a few megabytes of data.

The most important improvement for mining is the use of various methods to ensure fast downloading and uploading of new blocks.

First up is xthin, which is a way to send a 1MB block to all miners using only 25KB of data. This scales up linearly, so sending a 10MB block requires sending 250KB of data.

Another approach is a technique I call "optimistic mining" which helps miners upload blocks by slicing them into two parts. One part is a super fast notification of a new block. Just the block header is sent. The miner that receives such a header can verify the validity of its proof of work and start mining empty blocks based on this header. When the full block arrives, the transactions contained in the new block can be seen. All transactions in the memory pool are added to the new block, and finally, the creation of a new block will add as many transactions as possible, and then let the miner continue mining.

A mining node does not need to contain a wallet on the node, nor does it need to store historical blocks on the node, so they can be streamlined.

Many of these technologies have already been developed, and some are planned to be completed in the next year or so. In order to reach our goal of 50 million daily users in 5 years, most of these technologies are sufficient to enable a miner to stay connected to the Bitcoin network without having to invest in a high-end server Bitcoin node.

in conclusion

I'm trying to get to 50 million users a day. That's a huge increase from today. But to make sure we do it right, I'm setting the goal to be done in the next 5 years.

Scaling Bitcoin is a very boring job that requires very little effort, as modern simple systems have long been proven to easily scale blocks to 10,000 times the current block size limit.

Scaling the system as a whole requires more work, mainly because miners have not yet received many of the new features that are ready for safe scaling. Most of these features can be added in a few months, including using technologies like extremely thin blocks (xthin) and optimistic mining that have been developed for a long time.

My conclusion is that the goal of 50 million users per day is not only achievable, but we will easily achieve it in 5 years.

There is no mention of clever tricks like Lightning Network in this document at all, because there is no need. Bitcoin can scale on-chain fairly easily and with little risk. Ideas like Lightning Network are pretty high risk because there are too many unknowns.

The biggest issue regarding scaling right now is the protocol limit of 1MB block size. This protocol limit should be removed as soon as possible.