Quote from: HunterMinerCrafter on October 03, 2014, 05:02:23 PM

Quote from: Anders on October 03, 2014, 04:31:37 PM

I thought that maybe a distributed real-time server could solve that.

It certainly could. The block-chain *is* that distributed time server, this is the very function it serves. (We have no other proven design for such a beast. Wink

)

Quote

For example, the calendar time is taken to be a median value among the nodes in the network.

It is not so simple. Sybil could just overwhelm and warp the median, for example.

Quote

And then every let's say 5 seconds a chuck of transactions is committed to the distributed hash table.

The definition of "committed" becomes very problematic, here. This is concerning because this committal is strictly necessary as part of avoiding double spends. Without the proof chain securing consensus over a full history you end up in some messy situations. In any case you need "someone" to select and order transaction sequences *before* consensus is reached, and consensus has to be reached in a way that precludes re-selecting or re-ordering those transactions in the process, or after the fact, by any party. Further, you need to do so in a way that reaches at least a "50% + 1" security threshold in order to be able to assert majority consensus, which is much more difficult than it might initially seem. Most (arguably "all") DHT structures fall to only 1/3 collusion, in the best of cases. Bitcoin was the first p2p network to demonstrate any security threshold above this norm.

Ok, a distributed real-time server could be tricky to develop, but if we assume it's possible, then each 5-second block of transactions would prevent double spending since all transactions in the block are checked for double spending. How to reach consensus for what transactions should be included may be problematic although that too could perhaps be possible to solve.