HN Theater @HNTheaterMonth

⬐ seedpod01

Mr Sellout himself

Andreas Antonopoulous has a great talk on this: https://youtu.be/SMEOKDVXlUo

Spoiler: nothing, “blockchain” is one piece of what makes Bitcoin interesting.

This sound like just another case of misunderstanding the core technology. I can recommend watching: https://www.youtube.com/watch?v=SMEOKDVXlUo

How pointless.

The whole point of Bitcoin was to have uncensorable, decentralized asset that can be used to exchange value without any trust etc.

That is the only reason we endure this utterly shitty and inefficient blockchain thing, and we exchange money for this otherwise pointless online points.

I have no problem with ETH as cryptocurrency / smart contract platform. But this whole Enterprise Ethereum Alliance is just one big BS. Etherum community is trying to pump ETH value by associating with brand names, and corporations are trying to pump their stock value by presenting themselves as innovative. BS - empty words and marketing gimmicks. Just read through that page.

Just watch Blockchain vs. Bullshit: https://www.youtube.com/watch?v=SMEOKDVXlUo

⬐ ScottAS

The EEA was formed in response to Hyperledger, the heavily IBM-backed private blockchain. I think it was the only possible move. The risk of Hyperledger taking over the world of blockchain was too great. EEA is sort of to Ethereum/Blockchain what RedHat is to Linux. A necessary evil.

⬐ kgin

It's an industry working group to shape the direction of the Ethereum project, similar to a million working groups (ex Bluetooth) where companies are motivated to agree on and advance a technology.

Nothing about being in EEA says that company will use the public chain. Most of them will probably use private chains.

You presenting it as if it's possible for an open source project to recruit a long list of multinational corporations to sign on to collude on a pointless project just to make everyone involved look "cool" and get rich. If only.

⬐ squiggy22

There's even evidence of vote manipulation on this very HN thread on the announcement over on Reddit.

⬐ subway

Enterprise Ethereum has almost nothing to do with Ethereum the public blockchain, or crypto-currency. Ethereum based blockchains (that is based on Ethereum the software, not the canonical global instance of that software) provide an ability to create an auditable log of events.

Those events might be "who accessed my credit card account and when" or "who requested access to my health records and when". These chains can exist entirely independently of of the global "Ethereum" chain, and can operate entirely without the concept of a crypto-currency (aside from using it as a scheduling mechanism within your blockchain cluster).

People need to stop getting hung up the cryptocurrency aspect of blockchains.

⬐ 52-6F-62

I agree. Also, the EEA is more of an R&D coordination group than anything else. It's to see if there really is something there, and these companies have joined up their R&D departments and innovation labs to do so. They have a lot of industry pull, especially together -- so if there is something viable that comes out of it, most [North American/Asian at least] people can expect it to impact the way they do things, or the way the tools they use operate.

⬐ xorcist

That doesn't make sense. Read accesses couldn't possibly be logged. You probably wouldn't want sensitive information like health records in a block chain. The risk for leaks is obvious.

Both credit cards records and health records are data where there is a single authoritative data source. You want to know who actually accessed the data, and not any sort of decentralized consensus about the matter.

Agree about the wider aspects however, but those are probably about payouts to stakes in immaterial data or zero knowledge trading of cryptographic keys rather than your health data.

⬐ csydas

This is especially true for Health Records with regards to US Health Care, as access control is heavily monitored and Hospital Employees are instructed clearly and frequently that you do not access records for anyone you are not treating, accidental access needing to be reported, and so on. Confidentiality of the patient records requires a clear system to see who accessed what, when, and from where they accessed it.

Blockchain seems like a complete mismatch for such an endeavor.

⬐ subway

Just because a node can participate in a blockchain and cryptographically verify the chain doesn't mean the node can access the plaintext of every record in check chain.

Check out permissioned implementations like JP Morgan's Quorum.

⬐ hudon

> Ethereum based blockchains provide an ability to create an auditable log of events

If all they want is a log of events, why not use a tried and true database whose performance is more well understood? MySQL, Cassandra, whatever.

You can add the ability to audit the tables by signing data updates with public key crypto.

⬐ subway

By using a blockchain, you enable auditing organizations to participate in the authentication process. For instance, I might publish a private message to the blockchain that is an authentication request to resource X. A smart contract would then act on that authentication request, and publish either an ACCEPT or REJECT message. By bringing auditing organizations into the blockchain, every authentication attempt is sent to the auditing organization before access is granted.

The key is that every transaction must be made known to the auditors before it is acted on. By logging to a traditional db, you're at the mercy of the party responsible for sharing out those logs.

⬐ dfischer

Interesting. Seems like potentially cool ideas in government and politics for transparency.

⬐ hudon

Here is your schema:

DATA | auditor_sig

------------------

Now:

a) Assume 3 components: client, server, auditorService

b) How to write to server:

  1- client sends DATA to auditorService

  2- auditorService signs DATA and returns S(DATA)

  3- client writes (DATA, S(DATA)) to server

c) How to read:

  1- client reads (DATA, S(DATA)) from server

  2- client verifies S(DATA)

  3.1- valid? -> continue

  3.2- invalid? -> delete DATA from server

There are ways you can configure this to make either of these services have more weight (I made the server weak in this setup), and you can also give read access to everyone if you want it to be public (and only a subset of clients get write access). You don't need a blockchain.

⬐ None

None

⬐ baby

If I understand correctly, this is basically a database but in a merkle tree form + crypto. There is also no proof of work as it is not needed.

Maybe the client has key pinning baked in it, where each bank owns a key?

⬐ hudon

If you take Ethereum and you remove ETH/gas, you remove proof of work, you remove decentralized computation because that's just really inefficient and you want high throughput... can you really call what you have left Ethereum?

⬐ zeroxfe

Federated blockchains allow multiple parties in an industry (for example) to maintain a shared trusted database, with no single owner, or single point of failure. (Also, changing immutable data or posting fraudulent transactions requires collusion between multiple parties.)

This is why many large industries like healthcare and finance are actively exploring this space.

⬐ bduerst

Distributed databases can be configured to work that way as well.

Why do you need a proof-of-work blockchain? With such a small number of participants doesn't that weaken it's integrity to attacks, especially without capital incentives?

⬐ dx034

This doesn't work in reality. If you have two companies that need to work with common data it's currently very complex and costly to ensure that both parties can trust the data. That's why trust banks are so big in finance (e.g. Bank of New York, State Street) because it's often cheaper to have a third party you can trust rather than establishing protocols between two companies that auditors approve.

Blockchain can save a lot of money here by making the trusted third party obsolete.

⬐ zeroxfe

Traditional distributed databases require all nodes to be trusted to achieve consensus (e.g., with Paxos, Raft, etc.) Proof-of-work allows for consensus to occur even if there are malicious nodes -- for up to half the hashrate, which means that major collusion must occur to do something fraudulent.

In these industries the number of participants are in the hundreds -- past the point at which you can trust everyone.

⬐ omarchowdhury

Please someone answer this.

⬐ subway

There's nothing that ties a blockchain to proof of work. Proof of work just just one consensus protocol. For instance, JP Morgan's Quorum is working on Raft based consensus. https://github.com/jpmorganchase/quorum/blob/master/raft/doc...

⬐ hudon

The nodes are federated and you're still calling this a blockchain? What definition of the word "blockchain" are you using? Is this not more commonly called a "distributed database"?

⬐ cbr

To me, "blockchain" implies the individual nodes don't trust each other, while "distributed database" does.

⬐ derefr

A "blockchain", taken as a primitive, is essentially an append-only (geographically-)distributed database.

Consider: a Starcraft 1v1 ladder match is, by this definition, synchronized using a "blockchain", whose participating nodes are the two players' computers and the auditing ladder-server instance. That's not a reductio ad absurdam; that's actually what you should be picturing when you say "blockchain" generally: participant nodes, an event stream chunked into blocks, and a consensus mechanism for validating blocks.

Proof-of-work is just one consensus mechanism for blockchains. Mutually-agreed arbitration oracles (as above) is another. First-claim using a global hierarchy of signed-timestamping servers is a third. Etc.

⬐ subway

Replying to myself since we hit max comment depth (probably an indicator it's time to move away from this thread anyway). but to address the sibling reply by hudon, yes, a blockchain is a form of a distributed database (maybe highly replicated data base is a better term since every node has the full working data set).

The key trait of a blockchain is that each new entry cryptographically verifies all previous entries. At the end of the day, yes, a blockchain is a distributed db. It's a distributed db that never forgets.

⬐ hudon

> The key trait of a blockchain is that each new entry cryptographically verifies all previous entries

I see what you're saying. Basically: distributed database + signatures + merkle tree = blockchain.

I usually use this definition: decentralized and sybil-resistant database + signatures + merkle tree = blockchain.

So I think the key trait that turns a distributed database into a blockchain is not the merkle tree, but is its decentralized nature. Anyone can be a transaction validator and no one can prevent transaction validation.