Well, if you only need to maintain transactions within your own organization and there is full trust, why not just use a simple SQL database to record transactions instead of a much more expensive and complex blockchain? If there are multiple parties, what's to stop one of the nodes from, say, buying 1000 GPU instances on EC2 and massively increasing their hashing power. Even if you have some type of network control settings that only allow certain nodes access to the network, the proof of work could be distributed and you could just proxy the answer back to the machine that has access to the network.

The case for private ledgers is coordination among a moderate number of non-anonymous mostly-untrusted entities. (Whether this case ever exists is left as an exercise for the reader.) They can't use a central database but they don't need mining either; variants of BFT can be used that work as long as (n/2)+1 entities are honest.

If things are non-anonymous, you are far far better off having highly fungible but also highly audited databases.

Make it easy to do but also easy to undo anything, while also having a very large amount of transparency in the system so any "bad actor" can be dealt with swiftly.

That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly.

Abusing the system then no longer becomes a technical challenge so it removes the possibility that someone with the right technical prowess can "break" the system. Robbing a bank is the easiest thing in the world, just walk in and ask for money, it's getting away with it that's difficult.

> That seems to work for the banking system, where any malicious transactions are easily "reversed" (often just reversed on one side actually, 'paid for' by insurance / banks) and a large amount of auditing which makes it possible to clamp down on the bad actors quickly.

I work for a bank on blockchain projects. It's almost never this simple. You'd be suprised how much banking is paper based right now for the simple reason that no party wants a central solution controlled by any other party.

That's fascinating. Could you tell more about that, or maybe provide a link to more information? I find the topic interesting, and as a geek am inclined to find blockchain stuff cool and useful, but I know very little about the real-world situation/concerns.

A lot of companies in all kinds of sectors (finance, healthcare, etc) are looking into blockchain (or DLT) because it allows for a database model that is not centralised. This is great in situations where you don't fully trust other parties you are doing business with.

A lot of these companies are doing experiments using private blockchains (like the private ethereum network linked in OP). However depending on how much you trust the "other" parties allowed to mine (or sign blocks), you might still have the risk where one or more conspire against you and 51% attack you. Periodically putting a blockheader of your private chain into a public blockchain would be a great solution to this, as pulling off a 51% attack on bitcoin is rather hard.

Thanks for the info! Do you perhaps have some suggestions for what a good 'next step' is when it comes to understanding all this in more detail?

Can you speak more to where your industry is now in adoption? If there were some "major event" would companies like yours be ready to jump ship into cryptos quickly or are they going to be too late?

I read the article and he doesn't really answer why this is beneficial. If you have an arbiter of truth, isn't it just a really inefficient database?

Exactly. A blockchain is supposed to provide a set of guarantees so the nodes don't have to trust each other. If there is already trust, why bother with a blockchain in the first place? If there isn't trust, then there's definitely a possibility that one of the untrusted parties could try and attack or disrupt and the shared ledger.

Trust is not always so black and white (as on the open internet where anonymous people try to scam each other), in a lot of business cases there are different levels of trust which needs to be handled in a different way.

> The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply.

That's just wrong. Dangerously so. Maybe I'm just missing something in his protocol spec and he didn't really mean mining...

I've discussed this attack vector in more depth here[1]. Even if you made the mining function signing the block with your sk it'd still be wrong. Even if you forced the sk holder to have that same sk protect something really valuable, it would still be wrong... just have a larger disincentivize.

The whole point of mining is that it's non-auditable (w.r.t. who is physically mining) -- the only real metric you get is the speed of success which you can always mask by not releasing a block immediately. That's why PoW is a cockroach of a consensus protocol.

In the "we roll a dice to see who gets to append to the ledger next" metaphor for consensus, deterministic and PoS both require you to know the number of sides the dice have before you roll them. In PoW, you don't figure out the number of sides until after.

[1]: http://kadena.io/blog/MiningInPrivate.html

Not necessarily a miner collusion in China, just one of the authorized miners spinning 1,000 EC2 instances to make a 51% attack.