A Bitcoin full node could be modified to scale to much higher transaction rates than are seen today. Additionally, Bitcoin was designed to allow lightweight clients as well. Those lightweight clients only process small parts of the block chain (see simplified payment verification below for more details on this).

Please note that this page exists to give calculations about the scalability of a Bitcoin full node and transactions on the block chain without regards to network security. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.

Scalability targets

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, (1) however they never actually use more than about a third of this even during peak shopping periods. (2)

PayPal, in contrast, handled around 10 million transactions per day for an average of 115 tps in late 2014. (3)

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash.

Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.


The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 (in 2014) runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it. And we didn't even count faster CPUs and multiple cores.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of half 2016 the network is handling 3 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.


Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.


At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. A simple pruning has been implemented in the bitcoin full node software in 2016. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the UTXO set never becomes a serious bottleneck.

On the topic of actual harddrive space; at current 1MB block size the current mainstream harddrive would fill up after 75 years of blocks were stored on it. In real life people would have replaced such a drive with a much bigger one long before it reached 10% of that.

If we have ViSA levels with simple transactions we'd need 600MB blocks which result in almost 3TB of data per month. An actual node only needed to keep a day or two worth of blocks, though. So this would not actually be a limit to scaling.


Newly developed digital signature algorithms, like ed25519 have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a [Hardfork]. This ECC algorithm has also been shown to be easily accelerated using GPUs, yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.

Simplified payment verification

It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. bitcoinj is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

See also: Thin Client Security.

There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.

  • The Finite Blockchain paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.
  • Lightning Network, an alternative protocol for transaction clearance in which payment hubs set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with hubs.