We are at page 102 already. 
A great accomplishment! And to celebrate, I'm gonna drag back up a post of mine from page 89 that nobody responded to at all.
The subject is latency:
https://bitcointalk.org/index.php?topic=1346646.msg14038854#msg14038854I've been thinking about this some more. The post above discusses my desire to say something specific in the whitepaper on the maximum ISP latency acceptable for running a Lisk mainchain node. (I am worried we are going to have a lot of disappointed Active Delegates when they realize they can't run a Lisk mainchain node from home on their spare PC and they actually have to rent a server at Vultr for $5 per month). I also ask for confirmation that sidechains can run at slower block times that the mainchain, and if that alone would allow the use of slower, high-latency ISPs.
These are important and hard questions that nobody really knows the answers for yet. One of my first goals when Lisk goes live with 0.5.5 is to set up some cheap sidechain nodes and run some timing experiments to get some answers. I want to give my future sports dapp customers great service!
However, I've been thinking about this some more and I have more questions. So here goes.
First off, are we going to start Lisk on version 0.5.5 software and not 0.5.4?
Second,
what is the specific reason we are going to launch Lisk with a 10 second blocktime? Sure, that's the number Crypti worked hard to achieve. Sure, it is technically cool and impressive. Sure, it was originally intended to allow ultrafast merchant confirmations. But seriously....why? We are changing many things in Lisk that were originally done a different way in Crypti. Why not its blockchain speed?
Lisk is not promoting itself as a "coin for commerce" the way Crypti started out, so we don't claim fast merchant confirmations as a major selling point for Lisk. Also, most of the Lisk blocks are going to be empty - way above 90%, I'll bet - and piling empty blocks on at 10 second intervals produces nothing but blockchain bloat. Sure, Lisk has an efficient blockchain structure compared to Bitcoin or Ethereum and so has less bloat per block. And Lisk can handle large blockchain files just fine. The Crypti chain is doing fine at over 2 million blocks in length after two years.
But....if we launch with a Lisk block time of 20 seconds instead of 10 seconds, there would be no merchants saying we've caused them headaches by doubling the confirmation time. We would also cut our bloat growth rate by 50%. We would also have twice as long before bloat becomes an issue of concern... which it will, eventually, and we have to have the inevitable blockchain pruning discussion. So why not go from 10 seconds to 20 seconds for Lisk blocktime?
And once we start saying a Lisk blocktime of greater than 10 seconds is OK -
why not set the official Lisk blocktime as necessary to maximize high-latency home ISP participation by Active Delegates? Maybe that's a blocktime of 15 seconds, maybe that's 30 seconds, maybe that's a full minute of 60 seconds. Logically, a 60 second blocktime should be able to handle 6 times higher latency delays than a 10 second blocktime, right?
All I'm saying is that Lisk is an effort to start over and correct many of Crypti's deficiencies. Possibly the technically impressive 10 second blocktime may be one of those deficiencies. We have a few weeks before this Lisk train leaves the station and goes rolling full spead down the track. We should talk about just how fast that Lisk train is going to go.
