[lhl]

I'm all for deflating blockchain hype, but I found the overall tone of the article pretty disagreeable, and more importantly, wholly missing the point.

"In other words, the only thing previously stopping the standardization of reconciliation processes was the unwillingness of financial institutions to collaborate."

No, actually, the one thing the blockchain provides, which was literally unsolved before pre-Nakamoto, was a working implementation of "trustless" consensus. Turns out fraud prevention is kind of a big deal shuffling around billions or trillions among numerous third parties, but I'm sure that's just because they're "security-conscious egoists."

[the_mitsuhiko]

> No, actually, the one thing the blockchain provides, which was literally unsolved before pre-Nakamoto, was a working implementation of "trustless" consensus.

That's the part banks do not care about so I think it's largely irrelevant in the context of this article.

[coderzach]

> That's the part banks do not care about so I think it's largely irrelevant in the context of this article.

I have no idea where you got that idea, but it's not true. Which is why any deal that happens between institutions (and sometimes intra-institution) has an army of middle men who are responsible for verifying, monitoring, reporting, etc etc.

[brians]

But you still need them in a Blockchain world, and still need to trust them.

[wmf]

Or you could convince some other banks to vouch for your transactions if you vouch for theirs and then get rid of the middlemen.

[yummyfajitas]

No, because many of the middle men are there because you don't trust yourself.

Imagine you wanted to build a Hubspot/Triggermail/Vero type system, where you send emails to users when certain events are triggered.

Now suppose you use Sendgrid or Amazon to actually transmit your mail. You are unlikely to give very many developers actual sendgrid keys or access to call sendgrid. Most developers will call an internal API to send mail. This internal API will then perform a bunch of sanity checks - duplicate detection, rate limits, dirty word filters, etc.

Can you "cut out the middle man" by letting each internal service have their own internet connected SMTP server, and stop paying sendgrid and fire whoever builds the internal API? That would be pretty silly.

Similarly, a bank can't really get rid of the risk checks, money laundering checks, data normalization checks, etc.

[Ar-Curunir]

Isn't this similar to the cryptocurrency Stellar

[kordless]

You can use Stellar to build a gateway to another store of value, including bitcoin, dollar, mpesa, rai stone or, my favorite analogy, barn doors you have sitting in a shed somewhere.

[lhl]

I spoke at length w/ a friend working on mortgage-backed securities for GS a few years ago and dealing with third-party (and even intra-office) trust was specifically why he was looking into blockchains, but I'll admit to not being super familiar w/ R3's blockchain implementation. If anyone has a less diatribey and more technical resource they could link to that'd be great.

[tigershark]

It will never work in that use case. And I was hoping that the recent ethereum fork after the Dao debacle made it clear for everyone..

[to3m]

They will probably not be using the public Ethereum blockchain, so the fork won't be relevant.

[CyberDildonics]

I think Bangladesh cares about it by now

[nemild]

Is your argument that Bangladesh would have been safe if they were using a blockchain? Given their revealed security practices, I'd be surprised if they had the ability to secure any private keys from being revealed - and they would have had even less recourse with a blockchain based system (though admittedly, their recourse is limited even now).

[tigershark]

I don't think so. They would have lost ALL if the private key would have been compromised. In this case they even managed to block some transactions and recover quite a big chunk of money.

[gbarc888]

The banks aren't using trustless consensus. They're using a third-party "uniqueness service" to prevent fraud.

[mtkd]

I doubt this message will propagate further than technical forums - you're just going to have suck up the homogenization, pasteurization, retail branding and consumer promotion of a once great technology

[lhl]

Interesting, my original understanding was that they were using the blockchain for uniqueness for Corda, but it looks like it's optional: https://r3cev.com/blog/2016/4/4/introducing-r3-corda-a-distr...

This somewhat makes sense since one of Corda's departures is that consensus and validation are limited in scope to the participants.

[ojosilva]

And things like Smart Contracts are relatively new (1994), even though the concepts had been laid out in the 1970s. Smart Contracts are part of what makes blockchain more versatile, enabling transaction ledgers that can support the level of overwhelming (and sometimes unnecessary) complexity BFSIs can produce.

Unfortunately, even at this point, Smart Contracts probably still have many security challenges to overcome before banks can adopt it.

[Everhusk]

I think they are referring to post-bitcoin days, the quote was referenced from a paper released just last month.

Resistance to new technology is definitely a thing at banks, I remember when I worked at one I mentioned blockchain one day and everyone looked at me like deer in the headlights.

[zby]

The trustlesness comes with a heavy price of Proof of Work with its wastefulness, complexity and vulnerability to various attacks. I can understand why financial institutions don't want that part.

[runeks]

It shouldn't be necessary either. The proof-of-work is only necessary to avoid a central party wrt. which blockchain is the "right one". Financial institutions are working together with each other, they can easily just agree on which blockchain to follow. But without proof-of-work, the blockchain is just a database with atomic updates. I don't see why they would need a blockchain for that.

Ripping Bitcoin in two gives you two fairly uninteresting things: 1) hash-cash and 2) a database full of public keys/signatures. Only combining the two gives you something interesting: negotiable/fungible hash cash (hash cash that can be transferred from person to person via a distributed database).

[wpietri]

> But without proof-of-work, the blockchain is just a database with atomic updates. I don't see why they would need a blockchain for that.

I have been asking this question for a long time and not yet seen a satisfactory answer. At this point I'm sure that either I or a bunch of blockchain advocates are missing something important. Glad to know somebody else sees the problem too.

[bendbro]

I had this feeling when I was discussing it here.

https://news.ycombinator.com/item?id=12044767

[dgreensp]

I think by "blockchain" they mean hashed blocks that include the hash of the previous block and can be synced; basically git.

[TillE]

That doesn't gain you much besides a definite order and a way to check integrity. Useful things to be sure, but nothing a traditional database can't do.