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
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.

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.

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

I also voice my support for an increased blocktime of 2 minutes.

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

I posted on the issue in BCT. https://bitcointalk.org/index.php?topic=583449.msg12564758#msg12564758 My thoughts on this remain that raising the block time can only be justified on technical grounds. smooth has made a good technical argument for an increase to 2 min; in particular because of a significant increase of the popularity of Monero leading to an increase in the percentage of orphan blocks, which in turn can lead to instability in the blockchain. It also also my understanding that this increase has strong support of the developers. For these reasons I will support an increase of the block time to 2 min for the coming hard fork in six months.

It should be noted that the emission remains the same since the per block emission will be doubled.

It should point out that this does mean a significant compromise since a recipient of Monero will no longer have the option of accepting after an average of 1 min with 1 confirmation; having instead to choose between 0 confirmations and now more secure average 2 min wait for 1 confirmation equivalent to the old 1 confirmation. This can be significant for a service such as XMR.TO.

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

I am in favor of an increase of the target block time. I trust the core team regarding the best interval to be chosen.