Should factom have a shorter blocktime?

A shorter block time probably isn't the answer to most question someone would ask about how to improve factom.

In the whitepaper, we had a 1 minute block time, and that would get aggregated every 10 minutes into an anchor. After learning a bit about what we were trying to build, with block times that were short, we wouldn't get the aggregation benefits that having multiple entries in a chain would give.

If you have a bunch of entries in a single chain, then those would all get aggregated into a single Entry block, which would boil down to 64 bytes in the Directory block. The Directory block is something that all users need to share in the system. Getting that globally shared structure as compact as possible was one of the project goals. (This is why Factoid and EC blocks are handled separately from directory blocks. By shortening the blocktime to 1 minute, if someone is putting a bunch of entries into the blockchain around the same time, it would 10x the amount of their part of the shared data that everyone reading the blockchain would need to parse, for all time. So this is taking a perspective from looking at the historical blockchain. At that point it won't matter if the blocks were 10 minutes or 1 minute long. (OK you could argue that there would be more resolution with a 1 minute block time, but the answer to that is that all Entry blocks already have minute markers in them. That will show which minute in the 10 minute block time that a particular entry was included into the process list, for a historical perspective)

I think the main desire for a shorter block time would be to have faster feedback from a real time user interface perspective. By having 1 minute blocks instead of 10 minute blocks, people will get feedback 9 minutes faster in worst case. While true, that is still slow from a user feedback perspective, and there is a better answer.

All the current infrastructure deals in blocks. It is easier to deal with blocks, for many reasons. When a block is saved to the database there isn't a whole lot of expectation that it gets undone. (it can happen, but it is rare and most systems handle it poorly, but I digress). Most of the factomd APIs deal with data that has been saved to the database. This is mostly because we want to provide correct answers, and the nature of distributed consensus means that reporting about non-finalized things is probabilistic. That being said, there is nothing in the protocol stopping an API viewing and applications using data that is in the process list. In the coming years I do expect explorers and other infrastructure to give feedback to the user based on where in the process flow a particular transaction is in. There is some of that info already, foe example the pending-entries call: The ack call shows the details of how far along a transaction is on its way into the blockchain as well: Looking at this info would give a much better user feedback than merely having a shorter block time.

It also comes down to human levels of attention. Longer than 10 minutes is probably too long to really hold someone's attention to wait on something. If people want something more instantaneous, then looking at acknowledgements is the way to go, and that happens within seconds. (waiting for an EOM gives a bit more assurance that all the federated servers have seen your entry and your data isn't off on a fork somewhere, but that is a real edge case. Also, the current APIs are polling based. Again, there is nothing in the protocol that will stop callback style APIs that will give instant feedback when a network action is detected locally.

All this to day, a shorter blocktime is not the answer to a better user interface. Giving users better visibility into the block building process will give a better user experience than faster blocks.
Thanks for opening the discussion Brian.
I am a bit confused about the way you bring the topic though, because it seems you only find disadvantages to idea, so I am wondering why do you propose it? Generally I expect people bringing an idea to back it with some pros and few cons, which is not the case here ^^' Can you give us a bit of context why you're putting the topic on the table?
Speaking for Sphereon. We would certainly like to know asap about the entries. In the process list is fine for us. With current pause/stall mechanism I guess shortening the block time from 10 to 1 minute for instance, would only decrease the risk of an entry not being anchored into the block. As a pause/stall doesn't happen too often I am not sure whether changing it would add much benefit. What would be cool I guess is if a node could do callbacks itself instead of relying on 3rd party application on top that do that.
I’m for keeping 10 minutes blocks.

1. Bitcoin blockchain operates with 10 minutes block, and having 10 minutes for dblocks looks clear for everyone — 1 dblock = 1 anchor = 1 btc block

What if we have 1 minute dblocks?
Will we hash batch of 10 dblocks and anchor this hash into btc once every 10 mins?

Looks more complicated and less clear.

2. 10 minute time interval is OK for almost all types of data except games, but even 1 minute is too long for game apps.

3. I may comment from the Open API side — I design it to allow users to operate with all chains & entries — incl. processing chains/entries.

From the Open API user experience there is completely no difference between 10- & 1-minute blocks.

4. Having 1-minute blocks = having a larger size blockchain. Look at EOS? How much their blockchain — terrabyte(s)? I like how compact Factom is.