Quote from: 5h4do3 on March 23, 2017, 03:18:24 PM

eg. bitcoin block every 10 minutes+-... 12.5 btc reward "yay" block size 1mb +-
change to block every 1 minute 1.25btc reward per block "yay" block size 1mb (same same but different) scaled 10 fold.

1. messing with this involves
a. changing the reward mechanism - ugly thought, distrust that if it can be changed to 1.25 easily .. it can also be changed to 200000000000000 easily
b. changing the difficulty mechanism - ugly thought, 10x less hashpower required .. 10x more vulnerable to hash attack
c. changing the reward halving events from every 210k blocks to 2.1m blocks
d. issues with propagation

thats alot of rule changes just to still get 10mb every 10 minutes.. (data passing down cables over 10 minute average, no matter how you play with it as either 1x10 or 10x1)

ok lets delve into 1.d.
imagine it takes 10 seconds to get a block, validate it and ready to relay it out.
in 60 seconds the data has relayed through 6 'hops' of nodes.

..
but remember the block timing is not an exact science of 10min.. its an average. some blocks are solved in 2min some in 40 minutes.

so if we went to a 1minute average.. some blocks can be solved in 20 seconds.
meaning some nodes havnt even got the first block before the second block is trying to get around the network..
.. see the issue..?

this is why 10mins was suggested.. enough time to propagate around and have breathing room before the next block pops up even if that block was lucky to be solved in 2 minutes.
that cant be said for a lucky block of 20 seconds

and finally
2. even 1min is still too long for those complaining about the 10min queue when spending at the grocery store checkout argument