"In practice preparing for that kind of failure is a complete waste of time because you can never guarantee anything" Oh, but you can. Hence the decades of res

"In practice preparing for that kind of failure is a complete waste of time because you can never guarantee anything" Oh, but you can. Hence the decades of research. And determining exactly what can be guaranteed, when, and what the tradeoffs are, is the whole point. You're using refunds as a proxy for system correctness. That may make sense for your particular business case, but it doesn't make sense for many others. And it definitely isn't sufficient for a generic technical implementation that has to be able to be evaluated for an arbitrary business case.