Your proposal is interesting, and I agree the confirmation time is definitely a point of some friction. I like litecoin's 2.5 minute target, but even that could get unrealistically large for things like high frequency trading.
The system isn't going to do any magic. Too frequent blocks will cause excessive forking, so some things will just have to be done with layers on top of Bitcoin.
Would it be possible to re-integrate the forks instead, provided there are no conflicting transactions? It should be rare to have forks which cannot be reconciled. Example:
Chain 1: A(t1, t2) -> B(t3, t4)
Chain 2: A(t1, t2) -> C(t3, t5, t6)
Next: A(t1, t2) -> {B(t3, t4), C(t3, t5, t6)} -> D(t7)Instead of a single parent, Block D would list the heads of
all the chains its compatible with. The height would be the maximum along any path from the genesis block (i.e. height(D) = height(A) + max(difficulty(B, C))). In the event of conflicting transactions, it would be up to the miner of block D to choose a non-conflicting subset of the available chains.
about doing pretty much this. Maged has a few ideas how it would work. It would be interesting to see how to combine the ideas of dynamic block times and a different graph structure for the blockchain.