Hacker News new | ask | show | jobs
by dozzie 3149 days ago
The author apparently doesn't understand sh&t about the computer science background of blockchain, since he constantly throws "decentralized consensus" term to mean as a wrong thing. Blockchain does not do that (consensus problem, as stated by computer science, requires the protocol to actually terminate with an output; then, Lamport et al. in their original paper over thirty years ago proved an impossibility theorem that blockchain would break if it was solving the stated consensus problem).

All that blockchain does is to timestamp documents (transactions), the purpose of which is to tell which of the two documents was earlier. Then, the only purpose of proof of work and its derivatives is to artificially slow down signing the documents (transactions), so everybody would have about the same processing speed. This single assumption (that no single entity has computing power comparable to a significant portion of all the others combined) is what allows to choose longer chain in the case of double-spend incidents. When this one breaks, the whole protocol breaks.

There are also other dumb ideas, like that "blockchain is supposed to have a single linear history of transactions". It's not. It would if there was only one party that issues the transactions, so of every two transactions one would be marked as earlier than the other. It's wrong, since there can be incomparable transactions (usually concerning unrelated wallets).

> With proof-of-work, you can have multiple computers make additions to a blockchain without having them trust each other. That’s decentralized consensus.

No. That's distributed timestamping. Again, consensus is totally different problem (and well-defined at that), but author apparently doesn't know that.

> Instead of a network of miners, you use a single host. That host maintains a secure ledger which contains the host state and its activity log, including all requests and their results. That ledger is then published for clients to actively sync and monitor.

Congratulations, you have developed a centralized timestamping service and you have discovered that centralized service is functionally equivalent to a distributed one. Mind you, you're not the first to think about those.