1

I've read some books and articles on Bitcoin and feel like I've understood many of its concepts but I'm not able to find an answer to a question I've had for a long time:

How does the Bitcoin network adapt to an increased or decreased number of transactions per time interval?

I know that the network tries to constantly adjust the cryptographic difficulty so that new blocks are mined in 10 minute intervals on average. When the block size is limited, every block can only include a maximum number of transactions.

This means that miners need to prioritize some transactions over others (most likely those that pay the higher fees) when the number of incoming transactions per 10 min interval exceeds this maximum. When the number of incoming transaction decreases over time below this maximum, those unprocessed transactions (those with the lower fees) will be included in the next blocks.

But what happens if, over a longer period of time, the number of incoming transactions per 10 min interval never decreases?

Consequently, this would mean than all transactions with a fee that's not high enough never make it into the blockchain (or at least not for a very long time).

How does the Bitcoin network solve this problem?

(Surely, with increased adoption, there will be more than a couple hundred or thousand transactions every 10 min?)

1
  • It does not solve this problem :)
    – sanket1729
    Commented Dec 22, 2018 at 10:52

2 Answers 2

5

Why is there a limit? Why don't we change it?

No matter the number of transactions broadcast to the network, there is an implicit maximum number of transactions that can be included in a block (see @JamesC's answer), and the number of blocks found is regulated by the network's difficulty adjustment algorithm, aiming for an average of one block every ten minutes. This puts an effective cap on the number of transactions / second the network can confirm in the blockchain record.

You might therefore believe that adding an adjustment mechanism for the size or frequency of blocks would be beneficial to the network, but further investigation shows this to actually be detrimental to the health of the network. The reason there is no adjustment to the number of transactions included in a block (ie. an adjustable block size), is that such a mechanism would have undesirable implications for the ability of users to run nodes, and for the game theory of bitcoin mining:

For full nodes: In general, the larger a block is, the more computational resources (bandwidth, storage, computation) a node will need in order to validate it. So a larger block size puts pressure on the least capable nodes in the network, any increase in resource requirements should be expected to cause some number nodes to drop off the network. Thus we can see that a growing block size can be used as a DOS attack against resource-constrained nodes on the network, and this is obviously undesirable.

For miners: no matter the hardware, a larger block will take longer to download and validate. As a miner, this means that when you hear about a new block on the network, there is a brief period of time during which you will be downloading the new block, but are unable to begin mining on top of it before ensuring it is valid. This leads to an increase in orphan block rate, which will affect smaller miners more than larger miners. Thus we can see that a larger miner would be incentivized to create larger blocks, because the latency issues associated with large blocks will affect their competitors (smaller miners) more than it would affect themselves. Ultimately, we would expect this to concentrate mining power amongst a few large-scale operations, which is obviously undesirable.


What other solutions are there?

So all of that sounds pretty dismal in regards to scaling the Bitcoin network up to deal with a global transaction volume. BUT! The good news is that scaling the block size is perhaps the most obvious approach, but certainly not the only one.

For example, the lightning network (LN) moves transactions off-chain, allowing pretty much unbounded transaction volume to occur off-band between LN participants. Further still, LN channel factories could allow participants to transact with incredible cost savings. Note that there are trade-offs involved in using the LN, and the model of trust and security is slightly different than transacting on-chain.

Sidechains are also coming online, such an example is the Liquid Network created by Blockstream. Note that sidechains don't increase scalability, but they can increase scale, though again with a different security and trust assumption than that of the underlying Bitcoin blockchain.

Schnorr signatures provide a number of benefits over ECDSA, in terms of scalability we can see that signatures can be smaller (meaning less bytes per transaction), and more flexible signature aggregation (many participants represented by a single aggregate signature, effectively reducing the 'number of bytes per user' in a transaction). Note that Schnorr signatures are not currently used on the Bitcoin network, but many developers would like to see their implementation in the future.


In conclusion: lets reconsider what a 'transaction' can represent

To wrap all this up, I'll encourage you to move towards an understanding that a user interacting with the Bitcoin network to exchange some value does not necessarily have to map 1:1 to an on-chain transaction. An on-chain transaction can in fact represent a huge number of individual user transactions (eg. a transaction that opens a LN channel, or a transaction that includes an aggregated signature representing a huge number of individuals participating in a single transaction), or as Nic Carter put it:

[Bitcoin transactions] are nothing like Visa transactions, which they are commonly compared to. I like to refer to them as containerships, not parcels.

Which is to say that a single on-chain transaction can represent the economic activity of a great number of individual users, not just a single user's transaction.

So we can see that 'number of transactions per second' is not a perfect measure of the social scalability of bitcoin, instead the 'economic throughput per second' is perhaps more interesting. If we can include the economic actions of more users per transaction, we may find a more viable path to scale the Bitcoin network to a global level.

2
  • 1
    Very elaborate answer with lots of great links helping towards getting a broader picture. Thanks a lot!
    – Mischa
    Commented Dec 24, 2018 at 7:43
  • Love the analogy of seeing a transaction as a "container ship". There are very detailed explanations on this in the book Mastering Bitcoin by Andreas M. Antonopoulos which I just finished reading.
    – Mischa
    Commented Dec 24, 2018 at 7:49
1

The amount of valid tx data which can be confirmed every 10 minutes is bound:

  • 1mb (tx serialisation without witnesses)
  • 4m total block weight:

The weight of a single transaction is 1 * TX-bytes(incl. witness) + 3 * TX-bytes(without witness)

Therefore, there is no mechanism to accommodate for more transactions other than reducing their individual byte-size and weight.

2
  • So what you're saying is that (unless these restrictions are relaxed as part of a hard fork) Bitcoin cannot scale up and won't be able to do more than 2000-3000 transactions every 10 minutes – is that correct? (If so, that would be a fundamental design flaw which would prevent Bitcoin from ever becoming a dominant currency. That's hard to believe...)
    – Mischa
    Commented Dec 23, 2018 at 10:03
  • Bitcoin is non-scalable. That is necessary for decentralized validation, which provides the security for the system. Softforks such as segwit provide a logical increase in tx confirmation per block but that is not scaling in its strictest sense. Consider lightning or sidechains for alternative ways to transact offchain.
    – James C.
    Commented Dec 23, 2018 at 11:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.