[petertodd]

> 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]

> 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]

> 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.

[jrm4]

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]

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.

[DanielVZ]

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]

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