Comment by avar | Hacker News Reader

Comment by avar | Hacker News Reader

Parent Full thread

You're making a couple of assumptions which make your entire argument invalid in the context of a "private" blockchain between e.g. several banks.

The first is that you're assuming a race to the bottom where the banks will simply try to outspend each other on CPU. You can get a lot of the benefits of a blockchain where e.g. the 10 banks could all agree to each have 1 x86 box contributing to their part of the blockchain.

Any violation of such an agreement could be easily solved in meatspace, i.e. 9/10 remaining banks would just agree to ignore the chain maintained by the violator. Since they'd all recognize that they're getting /other/ benefits out of the blockchain without succumbing to some game-theory-esque race to the bottom.

Even if there's no such agreement the claim that any sort of alternate blockchain will use up the same resources as Bitcoin itself does is trivially refuted by various altcoins which use up less total CPU, since they're smaller networks.

The second faulty assumption is thinking that the only thing standing in the way of rewriting blockchain history is prohibitively expensive CPU resources. In the context of a "private" bank blockchain the banks could simply manually ignore a branch of the chain recognized as being produced by some malicious actor.

That leaves a bunch of valuable uses of the blockchain for banks. It's been mentioned as a replacement for the largely manual cross-bank money settling protocols they use now, replacing those with a blockchain would likely be much more secure and transparent, and any issues that arose by voluntarily running a "limited" blockchain would likely be smaller and more easily mitigated than whatever security issues their ad-hoc protocols have now.

There's no value of the work if there's meatspace negotiation, limitations like that on mining, etc, etc.

Tell me how this theoretical private blockchain would be better, in any way, than a git repository where each bank signs commits, commits them, and pushes those commits to all participating banks.

ETH vs ETC was essentially behind the scenes meatspace negotiation. The physical world is not as obsolete as some people think.

Today, banks clear transactions between themselves through the SWIFT network. By investing in distributed ledgers, a group of banks can collude to avoid settlement feees incurred by going through SWIFT.

That's the benefit to financial institutions, and the threat to SWIFT. The technology itself is nearly irrelevant. From a game theory perspective, what matters is whether their R&D is plausible enough that they can use the tech as leverage to negotiate lower fees.

Also known as cutting out the middleman.

Yes but the technology we're discussing would almost certainly need to be maintained and verified by the banks at some financial cost?

The banks own SWIFT.

The idea is to spend less money than the other guys.

> By investing in distributed ledgers, a group of banks can collude to avoid settlement feees incurred by going through SWIFT.

How does a distributed ledger remove/lower settlement costs?

Here's quotes from a bunch of people interested in the subject on how this would be useful, instead of me trying to repeat all of that: https://bitcoinmagazine.com/articles/what-are-the-use-cases-...

It would be useful beyond some custom git-based solution because if what you want is just a distributed ledger with safety & auditing built-in you can get that off the shelf by leveraging e.g. the Bitcoin codebase. If you're doing that with Git you need to write a bunch of custom software around it to arrive at the same result.

git is a distributed ledger with safety and auditing built in just as much as a blockchain is, if not more.

The bitcoin codebase doesn't provide anything as good as you describe.

For example, let's say you wanted to find, in the ledger's history, a transfer of $20 from $a to $b. With bitcoin, that requires writing custom software. Git has built in tools to find changes with certain contents, signed by certain keys, etc.

If you want to argue about what has more mature tooling for the banking usecase, you'll find that literally anything that isn't a blockchain, be it git or a sql database, has more mature auditing tooling.

Thanks for the link - but honestly, I didn't see any compelling use case listed there.

If you trust the counterparties enough to trust that they'll hold to the hashrate limitations, you are implicitly trusting that they won't try to screw you and take 51% control, in which case they can do whatever they want. The two concepts are literally one and the same.

Validating transaction settlement according to an agreed-upon set of rules is perfectly fine. The whole hashing thing on top of it makes no sense whatsoever for trusted counterparties: you just agree that if the block doesn't validate then it doesn't happen and nobody accepts it. The attacking bank is now "hardforked" onto their own chain that nobody else cares about.

Again, for trusted parties the hashing thing is entirely useless. A distributed ledger is fine, but not groundbreaking in a world with off-site replication of databases. You can probably hack something together with triggers for validation in like a week.

You don't need to trust everyone to hold to hashrate limitations, you have a closed network, you just need the majority of participants on the network to agree kick out any violators.

Here's an article describing how the majority of hashrate was reversed once for Bitcoin itself:

https://bitcoinmagazine.com/articles/bitcoin-network-shaken-...

The largest miners all agreed to switch to the 0.7 chain, even though the 0.8 chain had more CPU power. This could just as well have been done on a closed bank network by e.g. everyone agreeing that Deutsche Bank are being dicks and trying to take over the network, and simply manually ignoring what they're mining.

If you're one of 10 miners on a closed network and you know the other 9 will simply start ignoring you if you break the rules, you don't have any incentive to break the rules.

You also haven't come up with any plausible scenario for why one bank would even bother to do this. If you're using a private blockchain for e.g. a SWIFT replacement as discussed in this thread, what's Deutsche Bank going to do once they become dicks and acquire 99.9% of the mining power? Disproportionately pay for running the whole thing? They don't have any interest either in screwing up the network or approving double-spending or whatever, since they're also using this SWIFT-replacement just like everyone else is.

Claiming that this is "useless" in "a world with off-site replication of databases" is missing the point. You're just failing to imagine that there can be anything on the spectrum betweeen a 100% centralized system with 100% trust and a 100% decentralized system with 0% trust.

How is a group of 10 banks who needs a SWIFT-like system going to run a traditional DB with off-site replicas, say the primary fails, which replica run by the 10 banks does everyone agree to fail over to? You'll very quickly just need some centralized party to run the whole thing at a large cost, and you'll end up with SWIFT again.

This is the part that a private blockchain makes easy. You have banks or other private parties that all benefit from running a low-cost distributed ledger, they can firewall this off from the open internet, and all of them just have an interest in keeping the system going as-is at a low cost.

It's easy to monitor whether some party is breaking the basic rules of mining, and once you have that setup adding new banks becomes a much easier lower-trust operation than e.g. giving some random new bank read-write access to your traditional RDBMs SWIFT replacement.

Reply on news.ycombinator.com