Please login or register.
This location

Increasing the block time

smooth posted this 9 years ago

smooth | 9 years ago

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
EhVedadoOAnonimato posted 9 years ago Weight: -164 | Link [ - ]

I'm not sure I understand what are the instability problems...

The simple fact that there are more lost blocks and reorgs per se doesn't bring instability, at least if by instability you're talking about transaction confirmations. If the splits are honest, we can expect all transactions except coinbase to be on both sides of it. The confirmation speed will remain. And coinbase transactions normally take a long time to mature so they wouldn't be expendable before solving the split anyway. (right? or is it different here?)

Granted, there will be more losses to miners, but these losses will be the same to all of them. Well, not exactly, better connected miners would have better propagation, and in a way that's a good thing: you bring monetary incentives for miners to build up a faster network. Or even to evolve the protocol so that block propagation is faster (imagine how cool if Monero implements constant time propagation before Bitcoin :))

I don't think reducing space by having less coinbase transactions is a motivation for such a change. Coinbase transactions should be the least of your worries, if you expect Monero to grow.

Why is cryptonote more sensitive to reorgs? Is it because transactions might risk using a recent mixin which dies out in the reorg? How meaningful is the chance of this happening? And, if both chains have an identical copy at the same height of the transaction that creates your mixin option, is that even a problem at all?

I'm just questioning to understand why is such change wanted. Normally I'd be wary of changing important parameters like this unless really necessary.If it's just because you're concerned with a possibility that might never become true, I'd advice not changing right now. You can always hard-fork in the future if really needed.

Plus, faster confirmations are cool. :)

dnaleor posted 9 years ago Weight: -166 | Link [ - ]

if the choice is between 2 and 4, i would go for 2. If that is still to fast, we can always double later...

MalMen posted 9 years ago Weight: -167 | Link [ - ]

I am undecided between 2 and 4 minutes, but i am more faborable to 4 minutes blocktime, i think it will make the blockchain smaller and speed the wallet sync alot, at the current stage we have alot of empty blocks...

Peter posted 9 years ago Weight: -168 | Link [ - ]

The reasons for wanting to change the block time to 2 minutes are solid and I support the increase.

Shrikez posted 9 years ago Weight: -169 | Link [ - ]

2 minutes look fine

binaryFate edited 9 years ago Weight: -169 | Link [ - ]

I support 2 minutes.

  • This is the smallest time that reasonably feels fairly safe in terms of orphans rate.

  • The characteristics underlying the orphans rate (propagation time mainly) are only going to improve - globally - monotonically. Experience from Bitcoin suggests even with far more bigger blocks than current Monero ones, we'd still be ok.

  • Important to stick to smallest reasonable value, as a short block time is still useful and confortable in usage. (I can think as an example to xmr.to: the longer the block time the harder it is to pay bitpay type bills that are limited in time).

Myagui edited 9 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 9 years ago Weight: -170 | Link [ - ]

Going to +1 Myagui here.

antw081 posted 9 years ago Weight: -170 | Link [ - ]

I support a change to 2 minutes.

JohnnyMnemonic posted 9 years ago Weight: -170 | Link [ - ]

I support an increase to 2 or 4 minutes for reasons already stated.

DaveyJones posted 9 years ago Replies: 1 | Weight: -170 | Link [ - ]

If LTC-style is considered as the fasted with the least problems... why don´t we go for 2.5 minutes?

Reply to: DaveyJones
smooth posted 9 years ago Weight: -170 | Link [ - ]

I alluded to this in the original post. The block reward formula uses an integer power of two factor of the remaining base supply. It is more straightforward and transparent to change the power of the factor (currently -20, so with 2 minute blocks would change to -19) reward consistent with the current structure than it would be multiply it by 2.5, although that certainly could be done too (most obviously by doubling it and then adding half of the current value). If there were strong support for that instead I wouldn't have a problem with it.

fluffypony posted 9 years ago Weight: -170 | Link [ - ]

I support 2 minutes. At-risk services, such as exchanges, could lower their expected confirmations from 18 to 9, for eg., and it would come in ate ought the same time. There's also not a massive amount of variance expected on 2 minutes, so I'd imagine that a service requiring 5 confirmations could still have it done and dusted within 10-20 minutes under most circumstances. This is a lot better than Bitcoin where I've regularly had to wait over an hour for a block.

palexander posted 9 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?

Reply to: palexander
smooth posted 9 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).

Kazuki posted 9 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 9 years ago Weight: -171 | Link [ - ]

Let's do it (2 mins).