The block time effects the inflation rate, how rapidly coins are created.

A shorter block time would increase inflation and I doubt very many people want that.

I really prefer small block times. This is better to bet at block 400 000 after 8 years than 2 000 000 after not even two...

You, we need to be ready any change and understand what do we need. I want to reply in here for your other post on other topic;


Yes i know it is discussed a lot of ago, you are right but we are still facing to HF. If we need to HF with any way, we will discuss to again for best solution.

Inherent latency of TCP/IP networks will be more effective in smaller block size but i think smaller block time will be more effective than more block size because we can discuss to best timing it doesn't need to be 2 minute, we will prefer to 2.5 min, ... whatever.

An other example, if you are mining bitcoin, your network connection will be corruptible, In worst case; your miners will be affected for 10 minutes. Other hand, In worst case, it will be affected for 2 minutes.

Halving time will be set like block reward the original  supply plan. it won't be need to change.
In implementations, I don't worry about that, it would be adapt like SegWit.

-Update miner clients (solo/pool) What is it implementation version.
-Support new block timing.

What can we do more safe?
We will expecting like X block for auto support. Miners Pools just update bitcoin core clients.
We can set a timer like X Block (after [X-Last block]*10 minutes),  it will be supported automatically for all updated miners

10 minutes or 2 minutes, your still playing the real life argument of

"but i cannot just stand in a grocery line or the line at the rent office for 2-10 minutes waiting for a confirm"

even 2 minutes is still too long for the majority of arguments that are being poked at the 10minute average
hence the LN service as a NICHE and VOLUNTARY side service for those wanting quick 'service' (emphasis voluntary not compulsory)

---

also. you have to think of the relay network (propagation risks)
if nodes have 8 connections(as an example), it means to get data to all the nodes requires atleast 4 hops if everyone had the 8 connections each (degrees of separation/web peer connectivity)

imagine you download a block in 1second
imagine you verify a block in 2second
but then need to push it out to 8 nodes(8seconds)

3second receive-verify 8seconds(send 8 times) relay nodes receive = 11seconds per hop
44-55 seconds for whole network to receive it

knowing that the 10 minute rule was not a exact science but an average of many blocks over a timescale.

there would be many issues of higher orphans and fighting over blockheight compared to today. where by more blocks are found within seconds of each other before the whole network has received and settled on an fully agreeable new blockheight.

we already even with the 10 minute rule have blocks being found with 20 seconds of each other but then find one of them is dismissed and thrown aside because the network believes another block deserves precedence to be added to the blockheight.

---

thirdly messing with the reward halving and the timing may seem mathematically possible and only cause mining for reward to stop 8 years earlier affecting just 0.00733~btc of total cap
the sentiment of being able to change the amounts(although end result is so far away and so small deviation) opens up the floodgate of loss of trust that it will/wont be changed again but with a bigger impact sometime in the future

---

knowing that bandwidth and storage of 1mb/2min is the same as, say 5mb/10min
is not helping bandwidth or storage. so those debates will still continue aswell as adding the debate about propagation risks (as mentioned above)

all for a 2 minute AVERAGE waiting period which some people believe is still too long for real world use anyway
..
where as
a 5mb block (based on OP's DATA of scenario used over the standard 10minutes)
the relay propagation risk has more breathing room to get the blocks around the network before worrying about the other competition as much and also without worrying about the next block height after that being solved before all nodes get the first block.
plus it doesnt mess with the reward halving timing. rewards per block, difficulty retarget or the predicted 2140~ end day of reward mining

Some Exchange Markets try to push HF , it might be too late

Litecoin requires 6 confirmations,

If BTC moved to a 2 minute block speed , all they have to do is increase the # of confirmations to compensate for the increased orphans.

With BTC at 10 minute & 3 confirmations, average is ~30 minutes for a Safe Transaction

With BTC at a 2 minute blockspeed , confirmations could be increased to 9 confirmations for a total of 18 minutes

So the 9 confirmation BTC would be safer than the current 3 confirmation chain and be done on average 12 minutes faster.   
(This would counter the orphan FUD being spread by deadwit supporters.)


 

This is something I have been suggesting almost since I first joined Bitcoin talk. At some stage the 10 minute interval will have to be reduced for Bitcoin to stay in the market. It has been pointed out that there are problems with the creation of orphaned blocks, and that some people are working on possible solutions. I believe that this should become a priority now that core efficiency has been improved.