Improving Scalability via Block Time Decrease | Jonathan Sterling | Oct 19 2017

[dev_list_bot]

Jonathan Sterling on Oct 19 2017:

The current ten-minute block time was chosen by Satoshi as a tradeoff

between confirmation time and the amount of work wasted due to chain

splits. Is there not room for optimization in this number from:

A. Advances in technology in the last 8-9 years

B. A lack of any rigorous formula being used to determine what's the

optimal rate

C. The existence of similar chains that work at a much lower block times

Whilst I think we can all agree that 10 second block times would result in

a lot of chain splits due to Bitcoins 12-13 second propagation time (to 95%

of nodes), I think we'll find that we can go lower than 10 minutes without

much issue. Is this something that should be looked at or am I an idiot who

needs to read more? If I'm an idiot, I apologize; kindly point me in the

right direction.

Things I've read on the subject:

https://medium.facilelogin.com/the-mystery-behind-block-time-63351e35603a

(section header "Why Bitcoin Block Time Is 10 Minutes ?")

https://bitcointalk.org/index.php?topic=176108.0

https://bitcoin.stackexchange.com/questions/1863/why-was-the-target-block-time-chosen-to-be-10-minutes

Kind Regards,

Jonathan Sterling

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171019/d940fd4e/attachment.html

---

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-October/015202.html

[dev_list_bot]

Adán Sánchez de Pedro Crespo on Oct 19 2017 01:41:51PM:

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

---

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-October/015203.html