Ok So do we have devs testing out shorter block times? to see the effects, for example I heard someone here say litecoins 2.5min block time is wrking well but only time will tell. How much time will tell?
Are we saying that 10min is the sweet spot? WHo is testing anything less?
If we are definite that 10 confirms from a 1min block time = 1 confirm from a 10 min block time in terms of security ... then that means there Is no solution other than to reduce security.
Also when we say less secure what does this mean, Eg; If I spent a coin on a 1min block time and then we got 2 confirmations how is this less secure than 2 confirms on a 10 min block time?
And is the attack on this HARDER to perform on a small block time than the double spend attack which one can do with a 0 confirm acceptance in a 10 min block time? As far as I know a 0 confirm double spend attack is quite easy right? Simply use a mobile and laptop with the same wallet and send the same coin twice?
There's nothing to test, it is all statistically defined. Quite frankly, while it isn't necessarily obvious why 10 minutes was chosen without statistics, some effects of changes to the target block length are obvious without statistics:
1) The more frequently blocks are created, the less efficient the blocks wil be in terms of storage (each block takes a minimum amount of disk space, the more transactions are in it, the more space it will take, but the less of the total space used is wasted just to record blocks vs actually storing transactions).
2) The easier blocks are to create (vs a difficulty-based time-target), the more frequently multiple nodes will be submitting competing blocks
3) The easier it is to create blocks, the easier it is to create a chain of blocks secretly and release it in any kind of attack (double-spend, "51%", etc)
Another way to word why we are sure of this: Security of a transaction is not directly based on the number of blocks, it is based on how much hash power is behind confirmation and how long it has been behind it. With a 10 minute block average, you need enough computing power and luck to override 10 minutes worth of work from the entire network. With a one minute block average and two blocks, you only need enough hash power and luck to override 2 minutes worth of work from the entire network. To remove the imagined first block convenience, you can also look at it this way: 11 blocks is going to come around on the two-minute network before 2 blocks comes around on the 10-minute network, so assuming equal computing power, you sometimes have slightly more security slightly sooner on a network with shorter blocks, but that doesn't make it valuable enough to ignore points (1) and (2) above.
Regarding the "imagined first block convenience": the protocol states that all nodes will broadcast a valid transaction when they see it (a valid transaction does not use inputs from another transaction that is already showing on the network, preventing double-spends from using the entire network [double-spends have to be made via secret mining or broadcast of two transactions at the same time
so only part of the network is working on each of them, neither of which are guaranteed to be successful]). Statistically (as in, before you take into account that payment providers are centralized), this means that an unconfirmed transaction is generally on most of the network when a merchant sees it. Given this, and considering the expense one would incur to perform a double-spend and the laws one would be breaking as well, it is simply not worth it to attempt to double-spend for any transaction where you aren't scamming someone out of a very significant amount of money, so merchants generally don't need to wait for confirmations as long as the transaction can be reasonably expected to complete (for instance, it has a fee). For transactions where a double-spend would be worthwhile (probably buying something at least as or perhaps more expensive than a car), waiting for multiple confirmations is not really a big deal, and quicker confirmations would probably mean waiting for more confirmations anyway.
The only potentially real convenience to a quicker block confirmation I have seen suggested by anyone was by AliceWonder, and that is if you spend from one input, and need to spend from the change output of that transaction down the street, you might not be able to send the new transaction until there is a confirmation, but I don't think that is 100% true. I believe it is possible to create and send transactions from unconfirmed outputs, they just can't confirm until their parent transactions do, too. However, even if that weren't possible, if bitcoin were common enough to be spending it in two places in close proximity to one another in a less than 10 minute average interval, and you had enough bitcoin to be spending at each of these places, there is no reason you couldn't have multiple inputs to spend from separately with just a little bit of planning. To that end, there are a lot of shops where you can't get change for a $100 bill, so it's not like planning ahead to split up the inputs is any different than planning ahead to have five $20 bills instead of one $100 bill. ETA: and you can make the change yourself instead of having to go to a bank or out of your way to a big store that can make change for the $100 bill.