4 ms·

they probably saw they don't need a slow and pricey blockchain for that. They could just get flight data from API's which already exists. For example in the EU

by lampe3 5y ago

they probably saw they don't need a slow and pricey blockchain for that. They could just get flight data from API's which already exists. For example in the EU all flight and all flight passenger data are stored in a DB. Just call that API check against it and pay out the cash. No need for a smart contract Cheaper, faster and as secure as any smart contract.

kybernetikos 5y ago
The thing that is interesting to me about this idea is that it is at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust. A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.
- lampe3 5y ago
  If I don't trust AXA I don't make any contract with them. If nobody trust AXA they will go out of business. I don't understand that logic. Why do I need more trust? Why should I care about the inner workings? At the end I want the money on my bank account Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in? It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet... Your trust issues are the problem here and smart contracts are not solving them
  - kybernetikos 5y ago
    > If I don't trust AXA I don't make any contract with them. One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-survey/ https://www.nsinsurance.com/analysis/the-geneva-association-... This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one. I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters. Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.
    - nieve 5y ago
      I'm sure stories of people having their insurance locked up in a buggy contract that won't pay out won't help increase trust in the industry.
- mellavora 5y ago
  > at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Far from the only way, unless you restrict the "only" to the ability to verify the software before it runs. if you allow the more general case, and the one I think most customers would care about, the concern is a verifiable guarantee that if their flight is cancelled, the insurance will pay out within X hours of the official cancellation of the flight. However, this is already verifiable by the dumb contract. Noting that this "dumb" contract can be enforced by law. The law (and the regulations on the insurance industry) are a publicly verifiable claim about the payments process. Yes, the public verification stops at the interface layer (and hides the application layer), but we usually accept this as a good principle of software design, don't we?

by lampe3 5y ago

kybernetikos 5y ago

The thing that is interesting to me about this idea is that it is at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Your point seems to be that having an automated payment for this case is easy. Yes, it is, but if it's running in a datacenter somewhere on hardware you control, the user cannot inspect or ask someone else to inspect the program that controls that payment. They can't see when it changes. They cannot be sure that a published claim that the payment is automatic will really be held to, or even that a trade reviewer will get the same treatment as them so it doesn't help address the deficit of trust. A smart contract gives you another way of making a publicly verifiable claim about your payments process. It's an additional tool in building trust.

lampe3 5y ago
If I don't trust AXA I don't make any contract with them. If nobody trust AXA they will go out of business. I don't understand that logic. Why do I need more trust? Why should I care about the inner workings? At the end I want the money on my bank account Everybody should have there own data center? Even my 80 year old grandma? In what strange world do you live in? It sounds to me like your living in a trustless world were everybody has access to a datacenter and fast internet... Your trust issues are the problem here and smart contracts are not solving them
- kybernetikos 5y ago
  > If I don't trust AXA I don't make any contract with them. One of the huge challenges of the insurance industry at the moment is that while research shows that 60% of people think insurance is important, only 30% have a positive view of the industry. https://www.nsinsurance.com/analysis/the-geneva-association-survey/ https://www.nsinsurance.com/analysis/the-geneva-association-... This leads to people still buying insurance, but buying much less of it than they or the industry would like. So yes, this lack of trust is leading to bad outcomes for both the industry and the individuals, but the argument I worry you're making - that the industry exists and so therefore is fully trusted is not a valid one. I think you've misunderstood my data center point. The point is that if our hypothetical insurance company has a brilliant automated payment system, but it's running in a place that it cannot be verified, then there's little benefit to trust. A smart contract solution on the other hand can be public and verified (without your grandma running a datacenter). None of this requires fast internet or even datacenters. Trust issues absolutely are the problem here, and a deficit in trust is leading to bad outcomes. Smart contracts are a tool that can be used to help, because they act as a public, transparent, verifiable statement of what the payments process actually is.
  - nieve 5y ago
    I'm sure stories of people having their insurance locked up in a buggy contract that won't pay out won't help increase trust in the industry.
mellavora 5y ago
> at the moment the only way that you can have a program make an automated payment and have that program verifiable by your customer. Far from the only way, unless you restrict the "only" to the ability to verify the software before it runs. if you allow the more general case, and the one I think most customers would care about, the concern is a verifiable guarantee that if their flight is cancelled, the insurance will pay out within X hours of the official cancellation of the flight. However, this is already verifiable by the dumb contract. Noting that this "dumb" contract can be enforced by law. The law (and the regulations on the insurance industry) are a publicly verifiable claim about the payments process. Yes, the public verification stops at the interface layer (and hides the application layer), but we usually accept this as a good principle of software design, don't we?