Hacker News new | ask | show | jobs
by proofofmoon 2917 days ago
With a SQL database, how do you achieve consensus on a proposed transaction without a middleman taking an arbitrary cut of the proceeds?
3 comments

The two parties either agree, or they don't. Full stop. Blockchain, or any buzzword technology, doesn't solve this eternal problem.

Third parties have historically been pretty good at sussing out consensus from the two. Judicial systems, market exchanges, etc.

When you pay a middleman, you are literally paying for Trust-as-a-Service, among other things (brokerage, etc).

Blockchain also costs money to build and maintain as a service, but it's probably the fact that the enormous cost is socialized that makes it an easy pill for many to swallow.

Who maintains the source of truth for this record of agreement? If it is one entity, that's the unaccountable middleman. Blockchain is not right for every environment, but there are industries where the middlemen are taking more than the equivalent of every party maintaining a blockchain team.

And court cases are even more expensive.

> With a SQL database, how do you achieve consensus on a proposed transaction without a middleman taking an arbitrary cut of the proceeds?

Um, there is still a middleman taking a cut with Satoshi's Glorious Blockchain. It's called transaction fees and they go to the miners who piss away small countries worth of electricity in order to validate a pathetically small number of transactions. You didn't think proof of work was free, right?

No reasonable industry would use Bitcoin's proof of work to transact between <10 semi-trustworthy parties.

We're talking about private, permissioned blockchains.

> permissioned

I.e. "trusted". So what does this bring over existing consensus algorithms, besides the "blockchain" buzzword hype?

Which ones are you thinking of? They should support immutability and auditability as first-class citizens while being resistant to third-party manipulation/coercion.
All consensus does in bitcoin is determine whether a transaction is possible or impossible (avoid double spends).

With a SQL database, this is not an issue because SQL transactions can have constraints preventing said double spend.That is to say, the SQL database can take a lock on the row and ensure no other concurrent transaction modifies it in parallel.

Consensus solves a problem that only exists in a decentralized system.

Since SQL databases are centralized, that problem doesn't exist. Even for multi-master / distributed SQL variants, there's typically a way to wait for a write to commit across N nodes before going on, which solves the problem much more easily.

In short, I think your question makes no sense.