Hacker News Reader

Comment by bepotts | Hacker News Reader

In all seriousness, what are the advantages Blockchain has over a public SQL database with limited reads and writes that also maintains a public transaction history? Cause when I hear people talk about the problems Blockchains solves (outside of cryptocurrency which is a whole other topic), I don't see what advantages Blockchain has over that. A public SQL database isn't the most "clean" solution, but it'll save everyone a bunch of time and money over the resource intensive blockchain verification process.

This idea that centralization is always evil, or that public actors are inherently untrustworthy and we need some mathematical algorithm to verify all interactions between them strikes me as one of those Silicon Valley idiosyncrasies that Silicon Valley haters laugh at.

View on HN

Append-only/log-structured databases are worthwhile (SQL databases end up similarly structured internally). "Mining" and all the overhead it entails is only worthwhile if you need zero-trust, and few if any use cases do.

true. it's not like Governments falsify data, forge evidence and all that. It's crazy to think the world needs zero trust.

How do consensus protocols help here?

Currently we trust information by the source it comes from. It’s an authority-based model.

Consensus shifts that trust from authority figures to others in your group. Bottom-up trust instead of top-down.

Sorry, I should have made more clear what I mean:

When Governments falsify data, in my opinion bottom-up consensus doesn't help, since governments then also could simply participate in that consensus-forming process (see 51% attack)

you think a government of Burma for example can 51% attack Ethereum? The purpose of all this is to put all their balance sheets and title deeds etc on the global blockchain not a private blockchain they control in their offices.

You think the government of Burma, for example could successfully attack an append-only public database product hosted and managed by another country where a large number of interested parites are acting as auditors?

are you seriously suggesting that small countries should keep their important data on centralized servers controlled by another country? its worthless to discuss the million reasons why this will never happen and why sorry

Government actions are important because of the identities involved. A statement that's non-repudiably signed with an official government key seems far more useful for holding a government to account than an anonymous consensus that "the government said this"

Maybe a different but related question worth asking is: what does a blockchain accomplish that cryptographically signed audit logs in a centralized database don't?

Setting aside the specific technical details, in concept a database of cryptographically signed audit logs and a blockchain aren't so different - blockchain adds decentralization and a trust/truth resolution formula, at the cost of a different set of scalability concerns. So when is that decentralization specifically useful?

The above, but published and witnessed (and signed) by others; I think that's often called a 'sigwit' system as shorthand.

Thanks for the reference! I got curious and looked it up. Turns out the term is 'segwit'.

But more to the point, turns out some cryptocurrency implementations move the transaction database to a segwit system because of the scalability problem.

Huh.

The main innovation is that blockchain is decentralized and yet still verifiable. A public SQL database is in nature centralized. Even if you were to try and shard it out to everybody in the network you have the difficult time of cross verifying such data heavy records.

> A public SQL database is in nature centralized

Why would a SQL database be centralized in nature?

Just as your n nodes hold the entire blockchain, you would have n nodes holding the entire SQL database.

Of course, you could have a blockckain only on one node, centralised. That wouldn't make it inherently "centralized", however.

Same with SQL databases.

There aren't any decentralised SQL engines really. There are distributed databases that provide SQL-like abilities, like Spanner, but they're optimised for huge scale and not low trust. They're still expected to be run by a single organisation, not a p2p network of many organisations.

I am the lead engineer on Corda, which is an open source 'enterprise' (i.e. institutional/industrial) blockchain-inspired platform. But if you don't like the B word you can think of it as a decentralised database that can be queried using SQL. The intro to the technical white paper describes some of the issues with "just run a public SQL database" approach:

https://www.corda.net/content/corda-technical-whitepaper.pdf

Why not just use a shared relational database? This would certainly solve a lot of problems using only existing technology, but it would also raise more questions than answers:

• Who would run this database? Where would we find a sufficient supply of angels to own it?

• In which countries would it be hosted? What would stop that country abusing the mountain of sensitive information it would have?

• What if it were hacked?

• Can you actually scale a relational database to fit the entire financial system?

• What happens if the Financial System™ needs to go down for maintenance?

• What kind of nightmarish IT bureaucracy would guard changes to the database schemas?

• How would you manage access control?

So, it's ultimately a system that tries to address these questions and many others too. If you can solve these issues then you can suddenly actually propose an entire market putting all data into a single database engine, and at that point things can get a lot more robust and efficient. But it just wouldn't be politically possible on any sort of scale to do that with Postgres.

Thanks for the writeup and the whitepaper.

I find it hard to follow the distinction between decentralised and distributed, especially since all of the points above would apply to your implementation, as well:

All the decentralised networks rise and fall with enough political pressure, becasue they all have a weak spot - some form of organizational structure that needs to be kept alive by some entity. In your case (from the whitepaper):

> A network map service that publishes information about nodes on the network.

The legal entity that will maintain this service will be faced with enough pressure to shut it down once the state in which this entity happens to operate in implements laws that happen to render some of the content in the database illegal.

If someone provides a solution to this, that would be groundbreaking. Until today, no such thing exists.

Why not jump on the Corda mailing lists and follow along as we work on these things?

The network map is a component I've spent a lot of time thinking about and working on, to make it more and more decentralised over time. Because yes a lot of users flag the same thing you have.

Corda has some simple features to mitigate this. For instance nodes have an additional-node-info directory where you can drop NodeInfo files. These act as overlays on the data received from the zone's network map. If the zone operator removes a party from the network map for some reason (maybe a court order, maybe a commercial dispute, or whatever) then you can just drop their NodeInfo file in this directory and it'll be as if they're still in the map.

So the idea is that the zone operator acts as a coordinator and provider of advice, but it doesn't have real control - node operators can always override whatever advice it's giving out.

But Blockchain cannot exist outside of cryptocurrencies. It's a system where popularity of a cryptocurrency is crucial for blockchain's security. So if it can't succeed as a cryptocurrency there is no blockchain to talk about. And once it succeeds we can start solving hard peer to peer trust problems with it.

Uhh HyperLedger from IBM is used to build blockchain systems without an unerlying cryptocurrency.

The use of cryptocurrencies within blockchain is to "promote" the adoption/distribution of a system. However, there are other cases where the stimulus for the adoption is non-monetary (e.g. access to the information) and thus a crypto-currency is not needed.

I agree 100% with this.

Maybe there are some slight advantages in some edge use cases - but if someone came out with a company that was "modified public SQL database technology" would people be investing their money and declaring it important to the future of technology? The answer would be no.

I haven't seen a better approach for decentralised verifyable databases yet. Postgres for example offers several approaches for mirroring or decentralisation however non of them feels certanly clean and all of them come with their own downsides.

I agree that we are not there yet to use it as a simple drop in solution for such problems. But we are certanly getting there.

Also there are no limited reads (or writes for that matter) every actor of the blockchain can modify their local version as much as they want.

The SQL database has to be maintained by someone and with enough political or legal pressure the maintainer can be forced to change it, not so with a blockchain.

Not as easily.

Instead, with a blockchain such pressure results in a fork of the chain, which in some cases (notably those involving token ledgers) may be even worse.

You've never heard of a blockchain fork? Where the developers change the blockchain... It's happened before for different reasons.

With enough political or legal pressure, you easily deploy a "51% attack" on the chain, and fork it as you like.

Just as the NSA runs almost all the Tor exit nodes nowadays, what would stop a government from running the majority of blockchain nodes and gain consensus majority?

> With enough political or legal pressure, you easily deploy a "51% attack" on the chain, and fork it as you like.

A 51% attack can do two things: Enable "double-spend" attacks - where the hash rate majority will ignore a block which was previoulsy mined and had a "confirmed" transaction, and instead mine from an older block which didn't have that transaction - but instead place a transaction paying themselves the money back. Anyone accepting payments over Bitcoin should use their common sense as to how many confirmations they should wait depending on the amount of money being transmitted. A 51% attack might eventually be able to write a chain longer than the current one, but it will take some time - and there is the chance that if it fails, the miner will have wasted his electricity costs.

The other attack a 51% hash power can perform is denial-of-service. They can ignore blocks containing transactions they do not want to include in the chain, and as long as they continue to mine the longer chain, those transactions will not succeed.

51% attacks can not change the rules of Bitcoin (although there are many people who wrongly believe this to be the case). If you try to change the rules, the rest of the network will reject your blocks and ignore you.

> what would stop a government from running the majority of blockchain nodes and gain consensus majority?

The costs, primarily. In the case that one party did accumulate a majority of hashing power, the network participants can agree to change the hashing algorithm to one which runs on commodity hardware. That would be many billions of dollars of specialized hardware equipment going down the drain, and will only make the system stronger by encouraging individual participation. Monero did this successfully, and plans to do it each 6 months to deter attempts to game their proof-of-work.

If you lived in Greece or Venezeuala, you may have a different opinion about your government's fiscal policies and trustworthiness.

Why do proof-of-work fans believe that the only alternative to trusting nobody is trusting everybody?

You get out of the proof-of-work mess by trusting one entity, and it doesn't have to be the government. And to use proof-of-work, you implicitly trust the people who wrote all the code you use anyway.

Not sure what you mean.

How do the people decide who to trust? An individual can be coerced and becomes a single point of failure in the system.

Your argument against simple verified ledgers was "but the government of Venezuela!". The simple solution is to not put the government of Venezuela in charge of your ledger.

Make it require multi-party consensus if you want, to reduce single points of failure. DNSSEC (for all its faults) runs on trusted multi-party consensus [EDIT: apparently not the way I think] and isn't a blockchain. But of course anyone or any set of people can be coerced, including you. That will never not be true.

"How do you decide who to trust?" applies to every endeavor in life, so if you want to go do philosophy instead of blockchain, fine.

What do you mean by "trusted multi-party consensus"? The TLD zones that actually matter are operated by individual organizations.

You know a lot more about this than me, so I'll defer to you.

All I meant is that:

* there is cryptographic consensus involved

* there is no single point of failure

Therefore it's a counterexample who people who claim that everything but PoW has a single point of failure. Am I wrong?

I don't mean to jump on you, but, yes: there are multiple single points of failure in DNSSEC, which is a simple tree-structured PKI, like we had in the 1990s. There's a "consensus" of a sorts between parent and child, but the parent can override it. Whoever controls .COM can, by fiat, sign Google.com records.

Got it.

Would you say that cryptography can create a system where you can trust a set of people, without having to trust one single entity, and without destroying the planet with PoW? And can you give me a better example to use next time?

(For what it's worth, I picked DNSSEC because it had a memorable example of a "key-signing ceremony", perhaps the only instance of such a thing I've heard of that wasn't someone launching a blockchain. I realize that DNSSEC sucks anyway.)

There's ceremony and some distribution for the management of the root keys. But almost nobody is a client of the root namespace; the most important namespaces are the classic TLDs and ccTLDs. The keys for those are controlled, by and large, by the governments that control those TLDs.

PoW solves this by economically incentivizing block production, and thereby creating a cost to anyone that would try to cheat the system. You don't need to trust any party, you trust the math.

You said not to put the government of Venezuela in charge of the ledger. But when the government of Venezuela sends armed forces to the offices of your trusted party to confiscate its servers and equipment, what happens to your ledger?

Yes, I know that's the argument for PoW, but PoW completely sucks in every way compared to trusting somebody.

If the government of Venezuela takes all your computers and puts you in jail, what happens to your Bitcoin?

If I'm in jail, my bitcoin still exists and when I get out, I could access it so long as I've memorized my seed words, or backed them up, or shared them with a family member I trust, who could use it while I'm incarcerated. It is not easily seized, and if you are careful, not easily identifiable.

Using trust to secure your ledger is like driving without insurance; sure its cheaper and more efficient, until it isn't.

Your family member that you trust gave your seed words to the government, under duress.

In a world that relies on not trusting anyone, you are screwed no matter what.

Putting a gun to someone's head will always be a security problem, in any system. In this case, it is not system threatening because no entity has power over the network.

I may have relied on my family to keep a password secret, but that affects only me. The government cannot coerce the entire system unless it is prepared to put everyone in jail. Bitcoin lives on, and will not be stoppable. This is the power of a trustless system.

Reply on news.ycombinator.com