Quote from: HeRetiK on October 27, 2017, 01:13:33 PM

Quote from: yshurik on October 27, 2017, 09:55:32 AM

Related to a lot of discussions about the increasing of block sizes in bitcoin.
Just interesting to hear a word from bitcoin core developers if there considered an approach of reducing time between blocks to be adaptive depending on network load (amount of transactions), of course in some ranges (can the network actually work in right way with time between blocks just as 1 minute) instead of a lot of attempts to increase blocksize and creates a lot of incompatibilities.
Also if it is considered, does it turn to be hard or soft forks?

Any solution that adjusts dynamically based on the amount of transactions is likely to be exploited, as spam transactions are easily created. Dynamically adjusting block times would require dynamically adjusting network difficulty, which even in a relatively simple use case such as BCH's EDA already prove to lead to problematic side effects. Additionally you'd need to find a new metric on how to define difficulty periods based on hashrate and to dynamically adjust block rewards, as otherwise you'd unwillingly increase Bitcoin's issuance rate.

Either way, as it would require some deep changes in the current consensus it would likely require a hardfork.

The approach as you describe it sounds kinda familiar to me, but I don't think Core ever considered it.

interesting, maybe a bit different approach, not dynamically adjusting network difficulty at all, but having an multiplier/divider like from 1 to 5, so max=5 means that pool of transactions is too high (like more 100K), so with miners will have choice - mine "standard" block in 10 minutes and get 12btc or mine "fast" block in 2 minutes but get 12/5 btc.