Blockchains have very few very specific usecases, and nobody wants to admit that their usecase isn't one of them.
My point is about the idea of using a blockchain to increase transparency and verifiability of a process that makes payments.
This is one of the 'very few, very specific' use cases that blockchains are good at.
Given that you seem to think that it's not that hard, I wonder if we have a different understanding of the requirements here.
We're trying to make the payment process more transparent and verifiable as a way of increasing trust. You say that we can do that with a database that allows some open access. I don't really see how.
For example - who runs that database? If it's the company that offers the insurance, it's a nonstarter - it doesn't help with trust. If it's some third party, then it's precisely as useful as the trust the customer has in that third-party. Such an approach could work, but in my opinion brings with it more difficulties than a blockchain solution in most cases.
Even if we do find someone trusted to run the 'database with some open access', there's still the question of being confident that payments are made according to the data in the database, and that the data in the database is updated according to the appropriate rules.
Don't oracles have the same issue?
Great point. And yes, there's a trust issue around oracles. I do think that these are dramatically less problematic than some of the other options though.
An organisation that publishes flight data and charges for it, is incentivised to produce accurate, timely data about flights.
If instead we have an insurance organisation keeping a database storing information about claims, its incentives are much more muddy.
I think this is another example of how trust isn't just a full on / full off thing, but that you can make meaningful improvements in trust that can have useful economic consequences even without solving it perfectly.
Depends on who pays, right? If their only consumers are insurance companies, they are incentivized to keep data in a way which is favorable to insurance companies (there are lies, big lies and statistics kind of deal). I believe this is what lead to the sub prime mortgage crisis.
I remember asking someone about this in the early days at the Bitcoin meetup in SF. This was when Ethereum was an idea, not a reality.
I pondered, "Will Ethereum have a way to query the Web in a transaction?". I never got a straight answer from anyone about how that would work well. Later, I discovered that Bitcoin script doesn't have loops, but is still somehow "Turing Complete" according to the inventor, who may or may not be the inventor.
My take then and my take now is that cryptocurrencies have some value for transitory things and imaginary value for more permanent things.
Blockchains are providing no value here, as the parent keeps saying.
Well yes, but I'm looking for something substantive rather than just repeated disagreement [Edit: this was unfair, Fabian2k's comments are all thoughtful and substantive, even if I disagree with where the balance falls].
My claim is that smart contracts can provide value by providing a payment process that is more transparent and verifiable.
I'm still not clear whether the disagreement is based on
* believing that having a more transparent and verifiable payment process is not valuable,
* or that smart contracts don't provide more transparent and verifiable payment processes than the typical insurance industry approach,
* or that smart contracts do provide more transparent and verifiable payment processes, but that there are other technologies that would be better at doing that (in which case, what are they?)
If the payment also is handled via the blockchain, there is a large number of potential concerns here. For me, I don't see how the really minor benefit here would be worth the rather big unknown risks. One important aspect here is that in fully automated systems like this, exploits are also much more efficient and can affect many more people at once.
It is also not clear to me how this would work for insurance at all. For automated and verifiable payment you need to deposit the funds into the contract somehow, and that is simply not how insurance works. If the insurance companies had do lock down funds like this, that business model simply would not exist. So in practice this would have to be some mechanism that only deposits a fraction of the funds. And then I, as a consumer that bought some insurance there would also be vulnerable if someone cleaned out that pool of money, e.g. by exploiting a flawed oracle or risk estimation process.
I don't understand enough of the details here to actually judge the risk, but to me that is a point against the entire thing.
And the problematic cases are the ones with enough ambiguity in facts or insurance conditions to make things messy, and those are pretty much impossible to automate.