I don’t think you can compare gravity that humanity have enjoyed for thousands of years to a system that have been there just for a decade and a half and people indeed tried and succeeded with using other “gravity” parameters on other universes 
.
Sure before we destroy the universe we will test that on a different planet before we do it on Earth 
People who actually based their work on having 10 minutes blocks (smart contracts?) come and speak how changing it will effect them.
There’s roughly 100 unspent perpetuities with (~46 BCH) mostly paying out monthly with a half-life of about 5.5 years. Lowering the block time would expedite those payout schedules proportionally.
For example, if the blocktime were changed to 1 minute, the half-life of those distributions would decrease by a factor of 10. So instead of paying out half the balance over 66 months, it’d be more like 6.5 months with payments ten times a month. Instead of paying out over 40 years, they might liquidate in 4 years.
Although a seemingly toy protocol, unspent.cash has the potential to be a kind of Mr. Frundles.
At this stage in the long bitcoin time-locking project, drastically reducing the blocktime would still prove the concept. There’s contracts with 1 year half lives where the notional value of principal just keeps going up.
That said, I personally don’t think changing the blocktime will improve security or help exchanges, merchants or users “trust” transactions more.
Coinbase.com will still say a 0-conf withdraw takes 6 hours. I’d expect an exchange that required 10 blocks will likely still require 100 minutes of hashrate and a checkpoint.
The current 10 minute block time would be an EXTREME advantage for a native BCH dex with relatively quick finality and high reliability. That is, if someone can go swap some wBCH for some wXMR instantly and know they probably won’t be in the 0.001% of trades that get’s rolled back on hyperDex, it gives the first seen 0-conf feel to trading, and would be a big draw.
In addition to adjusting the reward schedule as @freetrader suggest below, we might be able to use something like transaction version to separate which transactions expect a 10 minute blocktime and which assume a quicker one. i.e. v1,2 transactions are 10 minutes, v3 are 2 minutes, or something.
From very old discussions, I agree with our former overloads that any merchant transaction taking longer than about 3 seconds to reach finality is a deal breaker.
Also one should bear in mind that past discussions have always noted that if decreasing the confirmation time, one could lower the coinbase block reward and adapt the halving interval proportionally to minimize changes to the original payout schedule.
So let’s avoid giving a false impression that such a change would necessarily change the payout schedule or the total issued supply in a material way.
Please give more details about that proposal, you may have seen someone solve that, but it is new to me. How, technically, would you keep the current schedule while having more blocks per hour?
Current; Controlled supply - Bitcoin Wiki
This is about a point I’ve tried to make in the past as well, people that value this kind of trading will never be satisfied with a decentralized and “slow” system. Look at the movement of high frequency trading as a prime example. Even there the competitiveness of being nanoseconds before others is relevant to those that want that kind of thing.
They will in the end always benefit more from some centralized trading house, and that would benefit BitcoinCash too as the volume of transactions on-chain to support gambling like that is bound to overwhelm normal people actually paying their groceries on-chain.
To @tech, what evidence do you present that shortening the blocktime has any positive effects on things like payment providers accepting transactions? And why would you say that 2.5 minutes is Ok for me to hold up the queue in the supermarkt ?
If DAA target would change to 1/5 of the current (to 2 min) then block reward should also get changed to 1/5 the current at the moment of switching from 10 to 2, and halving heights after that would be accordingly recalculated as well. I guess we’d get to 0 a bit sooner due to additional integer division by 5, however if we’d have your increased precision CHIP then we could exactly match the original supply schedule. Anyway, even though nobody has worked out the details doesn’t mean it’s not a solvable technical problem.
The locktime opcodes would continue to work with “legacy” heights, like pretend you subdivide block 123 to 123.0, 123.2, 123.4, 123.6, 123.8. If the TX ends up in any of those, the locktime opcodes would evaluate as 123. To get more granularity would require a new set of locktime opcodes. Anyway, backwards-compatibility with regards to contracts is also a solvable problem.
I think the biggest ecosystem cost would be in having various blockchain analytics pages get messed up and display wrong info.
There’s also the increased headers size, and the question of orphan rates.
It’s simple. Confirmation times is a wildly accepted term that is used everywhere in the crypto world, 0-conf isn’t there yet. So I argue that people running exchanges and payment processors are just counting confirmation times and not really doing the task of computing the work (chainwork). Some providers require just 1 confirmation. lowering block time to 2.5 minutes means 4 times faster transaction for people.
I think such upgrade should be accompanied with marketing/public relation campaign showing the changes BCH have went through to improve stability (yearly upgrade schedule - double spend statistic) to reduce the possibility of exchanges increasing confirmation requirements for BCH.
Did I say that this should replace 0 conf or that sellers will have to switch to block confirmation after such upgrade. It basically reduces the uncertainty/risk and increases trust in crypto payments for merchants and service providers.
One additional point is that I’ve seen it multiple times that people are suggesting accepting 0-conf for payments less than $100 which is probably good for many merchants but what about payment processors who have to process tens or hundreds of $100s in an hour? What about payments larger than $100 USD?
I quote part of @im_uname Telegram post:
note that 2.5m will shift current 2h complaints (which sometimes happen) to 30m complaints.
I think this is a big advantage to reduce wait time specially when 1h or 2h blocks happen.
Why would the header size be increased? Or do you mean that the number of headers per time will increase?
Individual header size would be the same (80 bytes), but the total size of headers chain would be getting bigger faster.
The point is that the premise you are working on is false. It is based on hopium, not on reality.
instant transactions are in actual fact widely used in a large number of places. Townsville is the best documented one.
The fact that it already works today, but isn’t even more widely used is much more logically attributable to things like fulcrum not supporting double-spend-proofs in a way that is usable for a merchant. Which leads to the majority of wallets and point-of-sale software that uses this backend still not using the dsproof, which is still in beta for exactly that reason, it’s waiting for a major roll-out, see roadmap.
The exchanges are not going to lower their confirmation count based on any technical changes in BitcoinCash. There is literally no evidence at all to suggest otherwise. Anyone suggesting so will have to provide some actual evidence to support their claims since otherwise it is and stays hopium.
But you do touch on a really good point:
We have never in our entire existance had anything like a marketing or public relations campaign. I bet that the vast majority of crypto people have no clue about BCH’s instant transaction security. They all still are living with the belief that it is exactly like BTC but with bigger blocks. While BTC is effectively removing all zero-conf features and SPV features with the effect that it stops being usable as cash. We in BitcoinCash have to live in that negative shadow. And I agree it would be wonderful to somehow fight back.
Changing the blocktime is not going to change the perception of risk. As a result it will have no effect on those companies making decisions based on that perception of reality.
The positive here is that companies that actually understand the reality (goCrypto is one, as a good example of a payment provider) they are able to provide zero-conf products and their customers actually can accept BitcoinCash as cash. Which makes them win and eventually the BitPay’s of this world will adjust or get replaced.
Trust the open market, it never fails.
Imagine doing a PR campaign just for your users to find that they are waiting exceptional amount of time just because we inherited a number that some are not daring to change and because of being a minority chain. I’m not sure how much you use payment processors, transfer and deposit to exchanges but it really doesn’t feel right when you have to wait for one hour for just one confirmation. My own experience it’s about 50 percent of the time I had to wait for 30 minutes to 1 hours when dealing with services that requires confirmations just to get 1 confirmation.
When you mention Townsville do you really have data on the practice of the stores there? how many of them, how much volume they are processing. Do they accept 0-conf for transactions that are above $100, do they require ID? What exactly is their policy? Are they depending on payment processors or they are just using BCH directly.
Please don’t limit the discussion for store payments considering their share from usage of crypto currencies.
I’m not trying to undermine DSP or 0-conf but you can not undermine the importance of confirmations.
Tom, there are tons of cryptocurrencies around there, why would developers implement DSP just for us?
Using the same logic they are also not going to increase their confirmation requirements if we do lower block time.
One argument from @BigBlockIfTrue first reply and @bitcoincashautist reminded me of really worth considering is when lowering block time we also lower the work required to produce a block and this may increase risk of forks of smaller pools produced blocks by larger pools. Hopefully someone can check if this is a serious issue or have it happened before at all on BCH or chains with lower block time?
Is this the situation we will be in if our hash rate drops to quarter of it’s current one?
I am back from winter break now.
Do you guys need any help destroying above nonsense arguments? You seem to be handling it well, not sure if I should join in and ruin your fun.
So, to make this very clear. The way that changes in BitcoinCash work is, in short.
No changes to the protocols or consensus rules are allowed. They are immutable. No developer, or miner or whomever is able to change them as the changed thing will simply not be BitcoinCash anymore. This is your baseline.
Good ideas can come up and the people that believe in them can attempt to convince everyone else to follow this good idea. When everyone in the community agrees this is a good idea, then it followes we all agree to change those consensus rules.
Now, if you state that “someone” needs to do work, and you’re not volunteering to do the work, that’s your choice and I don’t mind. I just want to establish expectations with the above. It’s not convincing me that this suggestion is a good one.
Changes to the protocols or consensus rules are allowed - they are done via CHIPs.
When everyone in the community agrees this is a good idea, then it followes we all agree to change those consensus rules.
No, not everyone needs to agree. That was one of the last line of defense arguments from Core against raising the blocksize - that not everyone agreed. This kind of “extreme consensus” is not needed in the real world for changes to happen to the Bitcoin Cash protocol. Someone just needs to write a CHIP to motivate and specify the change well (looking at recent CashTokens and ABLA CHIPs as primary examples). Of course it needs to make a case for the change well enough that enough people want it so much that they’re willing to incur the costs of deploying and supporting it.
And even if everyone agrees that something is good in theory, it still needs someone to implement it.
So it does not follow that a change is deployed simply because some or all agree.
There is also no compulsion on others to implement anything. People implement things if they can and think they’re useful. If 90% agree something is useful, but 10% don’t, and the 90% implement it, and it becomes a success, those 10% are just going to find their products less in demand and maybe die out.
Just wanted to point it out to avoid confusion.
LOL, I guess the “in short” was too short for you? 
Excuse my bravity…
Since people talked about exchanges, this older video is still valid and people should consider its implications.
Was Joshua able to convince Coinbase of accepting 0-conf transactions as he was/still an engineer there?
Irrelevant, pretty much.
The ecosystem will automatically start accepting 0-conf transactions once Bitcoin Cash becomes the dominant way of making payments.
Despite nonsense claims from various parties, a successful attack against a 0-conf accepting merchant has never been done on neither BCH or pre-2016 BTC even. I still remember paying via 0-conf to coinbase and BitPay back then.
The unwillingness to accept 0-conf transactions is merely due to years of propaganda and (deliberate) malfunction [RBF, clogged blocks] on the Core side.
I can make an educated guess; based on solid, hard evidence; that 0-conf transactions for anything under $5000-$10000 in USD value are 99.99999% safe on BCH, because the attacks have been thoroughly discussed and the conclusion is that the attacks are too impractical and the risks are too high for a serious party(like a big miner) to even consider doing them.
Honestly you’re wasting time trying to convince the BCH community to decrease block time, while you actually should be trying to convince merchants to simply accept what works. You should rather, in fact, write to your favorite payment provider right now and politely inquire them about accepting 0-conf.