The time required by a transaction depends on three factors: block time, network propagation and hardware I/O. The block time is the interval between two consecutive blocks. Usually, the block time should be significantly higher than the other two. E.g., Bitcoin’s block time is 10 minutes. This is purposefully set so that the creation of a block requires enormous computing power. The network propagation is the time for data to travel from one node to the other. This factor depends on the geolocation and Internet Service Providers of the nodes. The hardware I/O is the time to read/write data from/to storage. Usually, this part is negligible since most desktop modern computers are already capable of executing hundreds of thousands such operations within one second. It only becomes significant when the transaction amount is huge.
We can see that the majority of the latency of Bitcoin originates from the block time. An seemingly intuitive solution is to increase the block size to include more transactions, or reduce the block time. However, adopting such upgrade could introduce bigger problems and even worse, lead to a catastrophic hard-forking.
Bitcoin uses two method to secure its data: asymmetric encryption algorithm and cryptography hash function. The first method ensures that no one can forge the signature of a transaction without obtaining the private key of the originator. Therefore, an attacker could, at best, only reverse his own transaction to instantiate a double-spending attack. The second security measure promises that if attacker wants to rewrite the history of a block, he must redo proof-of-work of all blocks after it, since changing even only one byte of data could make the whole blockchain different from before. Moreover, the hash that satisfies cannot be just any hash, but the one that takes billions times of of calculations to find. If a transaction is buried under six or more blocks, it becomes impractical for anyone to recalculate hashes of all blocks.
However, by reducing the block time, the power required by mining a new block will be inevitably cut short as well. Forking will be more likely to occur and attackers will be invited to perform more double-spending attacks with higher success rate. Accordingly, transactions must wait for more confirmations to be considered secure.
The other approach is to increase the 1mb block limit. This could be more problematic than shortening block time. The potential damages have been stated on the Bitcoin website, including:
A hard fork requires waiting for sufficient consensus.
Risk of catastrophic consensus failure
An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.
Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
European/American pools at more of a disadvantage compared to the Chinese pools
“Congestion” concerns can be solved with mempool improvements including transaction eviction.
No amount of max block size would support all the world’s future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.
Damage to decentralization
Larger blocks make full nodes more expensive to operate.
Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.
Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.
Less individuals who control hash-power will run full nodes if running one becomes more expensive.
A hard-fork is extremely dangerous because when it is adopted, the total computing power of the Bitcoin network will be split in two, since not all nodes can switch to the new consensus at once. Thus, the original 51% attack threshold will be reduced to 25% or even less. Currently, some of world’s biggest Bitcoin mining pools already control 20%-30% of the total computing power. This situation will endanger nodes following both the old and the new consensus. The original Bitcoin proposed that once the rules were set, they meant to be followed infinitely, like the Ten Commandments. While it is beneficial in some aspects that no one can arbitrarily change the rules, such as issuing more coins, it also makes scaling to higher transaction volume a much difficult task. Therefore, it is necessary to create an alternative blockchain, which preserves both decentralization and scalability.