Please login or register.

Increasing the block time

Many of the developers working on the project (not just the core team), along with several users, have expressed the view that the block time should be increased.

Some have suggested 2 minutes, some suggested longer times like 4 minutes or even 8 minutes (powers of two are more suitable than other numbers for technical reasons). Probably the most frequent suggestion has been "at least 2 minutes". I'm not naming names because I don't want to personalize the issue (it should be about the merits of the change) and if people want to come forward with their own views they can do so.

After some discussion, the prevailing (indeed perhaps unanimous) view among the developers supports a change to 2 minutes via the up coming hard fork in about six months. The block rewards would be adjusted accordingly to maintain the same rate of coin emission (twice as many coins per block so an equivalent number per day, etc.)

The trade offs are that confirmations will take longer of course, but confirmations will also be more trustworthy since they are less likely to be reorganized off the chain (currently there are many such reorgs per day, often a few per hour). On the positive side, the chain will be smaller, and syncing both a node and a wallet will be faster since there will be half as many blocks and half as many coinbase transactions to be stored and processed. During periods of low usage this means fewer empty blocks adding unnecessary overhead (and permanent chain size).

Perhaps the strongest reason to make this change is to guard against an increase in popularity (and the size of the network) causing the chain to become unstable. This has been seen on Bitcoin forks with 30 second blocks, where long chain (10 blocks or more) reorgs become extremely common and the network may fail to converge at all for long periods of time (or in theory permanently). Similar effects are seen to a lesser extent on BTC forks with 60 second blocks, and CryptoNote is somewhat more sensitive to the effects of reorgs, so staying at 60 seconds puts us in (or at best close to) a potential danger zone. The coins with the fastest block times that don't seem to commonly run into this trouble are the LTC-style 2.5 minute blocks.

Of course we don't know when or even if such an increase in popularity may happen, but if and when it does, we certainly want to have the foundation to support it (and much of the current development work on the whole project is intended to do so).

Questions and feedback are welcome.

Replies: 28
palexander posted 8 years ago Replies: 1 | Weight: -171 | Link [ - ]

Is this mainly to mitigate an attack vector? An adversary with minimal funds could easily re-org the chain and maintain the re-org? Also, is it possible to dynamically change the block time in reference to an attack? Or dynamically change the block time with some other type of event happening on the blockchain? For example: can the block time decrease as more hash power is added to the network?

Myagui edited 8 years ago Weight: -170 | Link [ - ]

I'm in favor of switching to 2 minute block times, for the various and well known technical reasons, most of which - if not all - are already expressed in the OP.

dEBRUYNE edited 8 years ago Weight: -170 | Link [ - ]

Going to +1 Myagui here.

Kazuki posted 8 years ago Weight: -171 | Link [ - ]

I'm too in favor of switching to 2 minute block time (as long as the emission is adapted adequately so it won't change)

Melbustus posted 8 years ago Weight: -171 | Link [ - ]

Let's do it (2 mins).

pa edited 8 years ago Weight: -171 | Link [ - ]

I'd prefer either 2 or 4 minutes block times over the status quo.

(I am curious, though, whether the GHOST protocol utilized by Ethereum is applicable to Monero and what its pros and cons would be. Perhaps that is off-topic in this thread.)

luigi1111 posted 8 years ago Weight: -171 | Link [ - ]

Just expressing my support for 2 minutes again; I think my position is clear from other conversations.

link posted 8 years ago Replies: 1 | Weight: -171 | Link [ - ]

Wouldn't this affect emission rate? Changing this needs to be careful.

Reply to: link
luigi1111 posted 8 years ago Weight: -171 | Link [ - ]

> The block rewards would be adjusted accordingly to maintain the same rate of coin emission --smooth, OP

cAPSLOCK posted 8 years ago Weight: -171 | Link [ - ]

I currently have no problem with increasing to 2. But I would like to hear more passionate arguments for/against each side.

nioc posted 8 years ago Weight: -171 | Link [ - ]

I vote yes for increasing the block time. I remember there was a discussion around a year ago on bct about increasing the block time but it is not clear to me now. fluffypony had an opinion about the length of time which I don't remember but I would give great weight to his opinion. From what others I respect have said, 2 minutes seems to be the way to go.

jml390 posted 8 years ago Weight: -171 | Link [ - ]

I like 2 minute block times.

Reply to: palexander
smooth posted 8 years ago Weight: -171 | Link [ - ]

The main reasons are stated in the OP. There might be some attack vectors that are opened up (or made easier) by the chain being less stable as well. Also, the block time indeed becomes shorter (temporarily) as hash power is added to the network, but that isn't itself an attack (indeed it is necessary since shorter blocks are what causes the difficulty to increase).

rocco posted 8 years ago Weight: -171 | Link [ - ]

but, will 2 minutes really do it? i can see that an increase of block time would be wise, but not really an argument about to not increase it to more than 2 minutes.

what would the difference be between 2 and 4 minutes? and what would we win if we go to 4?

enegery efficiency is also a point that has to be considered.

i can not judge it from a technical point of view, but i think this is the only view that matters, so i trust you guys, you know this baby best.

if the tradeoff is woth it, then take 4 minutes. if not then 2.

my wish would be you make this change only once.