Blockchains with fast confirmation times are currently believed to suffer from reduced security due to a high stale rate.
As blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not "contribute to network security". Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower, A will have a risk of producing a stale block 70% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high, A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process. Another possible implication of reducing the average block time is that block size should be reduced accordingly. In an hypothetical 5 minutes block size Bitcoin blockchain, there would be twice the block space available for miners to include transactions, which could lead to 2 immediate consequences: (1) the blockchain could grow up to twice the rate, which is known to be bad for decentralization; and (2) transaction fees might go down, making it cheaper for spammers to bloat our beloved UTXO sets. There have been numerous proposals that tried to overcome the downsides of faster blocks, the most noteworthy probably being the "Greedy Heaviest Observed Subtree" (GHOST) protocol: http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_full.pdf Personally, I can't see why Bitcoin would need or how could it even benefit at all from faster blocks. Nevertheless, I would really love if someone in the list who has already run the numbers could bring some valid points on why 10 minutes is the optimal rate (other than "if it ain't broke, don't fix it"). -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev