> There is nothing that a Stripe controlled blockchain could offer that a database could not.

One way of thinking about a blockchain is to think of it as a shared datastructure to keep databases in sync. Any time you want to distribute your database over more than just a single central place, in a cryptographically secure way, you're probably going to re-invent a blockchain to do it.

▲

3PS 6 days ago | parent | next [-]

> One way of thinking about a blockchain is to think of it as a shared datastructure to keep databases in sync. Any time you want to distribute your database over more than just a single central place, in a cryptographically secure way, you're probably going to re-invent a blockchain to do it.

Even more specifically, a blockchain is for when you want Byzantine fault tolerance, i.e. you don't trust one or more of the actors involved. This is the main distinguishing feature of blockchains IMO, the reason we have proof of work, proof of stake, etc. It's also the main thing I saw people getting wrong when using blockchains during the earlier waves of cryptocurrency fever; most proposals for blockchains did make sense as distributed public ledgers, but didn't really need the extra computational overhead because only trusted parties were adding blocks to begin with.

▲

petertodd 6 days ago | parent [-]

> Even more specifically, a blockchain is for when you want Byzantine fault tolerance, i.e. you don't trust one or more of the actors involved.

Often yes. But also blockchain's can be useful simply for backups and scaling: by cryptographically linking every bit of data together you can be confident that you actually have a complete copy without any errors.

Git is basically a blockchain for this exact reason: starting from a git commit hash, git works backwards, checking that every byte of data is what it should be. Similarly, modern filesystems like btrfs use strong (if not cryptographically strong) hashes for this same reason.

Though in a sense, you're still correct: the "actor" you aren't trusting here is your own computer hardware.

	▲	3PS 6 days ago \| parent [-]
		I think you're technically correct here: if you just have a bunch of Merkle trees where each one tracks the hash of the previous block, it would be accurate to refer to it as a blockchain even if you're not bothering to implement any of the distributed consensus algorithms that cryptocurrencies are actually known for. It's probably not the first thing that would come to mind, but it is a correct way to use that word.

▲

jrm4 6 days ago | parent | prev | next [-]

I understand all of this and I stand by my claim of pointlessness.

Stripe, nor any other bank or bank-esque thing needs this because they have already well solved their problem of "trust."

"Blockchain" is pointless overhead here.

▲

paperpunk 6 days ago | parent | next [-]

I wouldn't really say trust is a solved problem in cross-border transfers. Why only today I've seen transactions where:

- an intermediary credited another institution only to realise later they didn't have the money, and have to beg pretty-please to return the payment over a SWIFT message (there is no guarantee here, at best there is "market practice" which is basically just manners, but for banks)

- an intermediary failing to credit the next institution because of a processing error, but when inquired from remitter claiming they had in fact credited it

Many of these cases are very expensive to resolve. Far more expensive than the value of the payments in question. And for that reason they are often left unresolved.

Now I don't know if I'm convinced on stablecoin remittance, I find many of the counter-arguments extremely compelling, but some days I sure do think gee it would be nice if everyone was transacting on a shared public ledger and I could have some certainty of the status of a transaction.

▲

degamad 5 days ago | parent [-]

> an intermediary credited another institution only to realise later they didn't have the money, and have to beg pretty-please to return the payment over a SWIFT message (there is no guarantee here, at best there is "market practice" which is basically just manners, but for banks)

But this situation is not made any better by a blockchain - there's still no way to reverse a transaction except asking nicely and hoping the other party obliges, right?

	▲	paperpunk 4 days ago \| parent [-]
		I was only disputing parent assertion that trust is a solved problem and that banks don't "need" a solution. I haven't the foggiest if stablecoins solve these problems any better. In theory I think all participants having visibility into the ledger would at least answer the problem of "where actually is the money", but I'm not even sure of that though because of fiat on/off ramps, custodial arrangements, roll-ups that might happen off chain, etc. I don't know if you could use smart contracts to encode a recall/dispute resolution process into transactions but that's very hand-wavey and possibly collapses under scrutiny! All in I've no idea if crypto helps us here but I do think we have a long way to go either way.

▲

DanielVZ 6 days ago | parent | prev [-]

My guess is that their solution to the problem of “trust” has enough overhead that it makes people lose money because of time or middleman fees.

▲

kiitos 6 days ago | parent | prev [-]

this is such a bizarre position, what you're describing has been not only possible but actually implemented in real-world systems for decades before even the idea of a blockchain was thought up

blockchains solve a self-invented problem