[pfraze]

Actually I appreciate the defense, but that's not what I'm claiming. I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain. Single nodes don't have the problems of uncertain ordering or conflict resolution because they can provide strict consensus.

[dozzie]

> I'm claiming that decentralized consensus gives only a minor gain over a single node maintaining a well-monitored blockchain.

Do you also claim that a one-way hash function only gives a minor gain over a B-tree? Because document timestamping and establishing consensus are different problems.

[pdkl95]

A proper hash function provides a lot more than a timestamp. A service with a B-tree (or other traditional database) can rewrite history. Even if have a copy of the db, it's difficult to prove that your version is the service rewrote their version.

If a service wrote all transactions into a log in a way that allows for easy verificatio9n of the validity (including order), and the parties using the service regularly check that log, those parties can demonstrate that the service is acting correctly.

Questions about transaction order and consensus are separate problems, which may not be necessary, depending on the nature of the service. The point, I believe, is that some problems only need some of the features usually associated with "blockchains". We are only beginning to find the interesting uses for Merkle trees, and thus shouldn't blindly use the current bitcoin-style design when the current problem could use something similar,

[dozzie]

> A proper hash function provides a lot more than a timestamp. A service [...] can rewrite history.

I think you should verse yourself in cryptography before any discussion about it, including talking about blockchain. You seem not to understand what cryptographic timestamp is and what purpose it serves. Wikipedia has a nice introductory article approachable by a layman under "trusted timestamping" title.