I am a big fan of heyguevara, and happily disagree with you on regulatory approval and access to re-insurance markets: these need to be addressed, and we are happy to have discussions with insurance brokers and regulatory bodies to do that. as soon as those risks are reduced and some examples established, smart contracts will make it very easy for any group of people to start their own p2p insurance with their own parameters and rulesets instead of relying on less flexible central platforms.
Appreciate it, thanks. Don't misunderstand I totally respect anyone willing to get stuck into this stuff... I just think you're making a rod for your own back by adding this "distributed" requirement.
I don't see customers caring about distribution, whereas it would make several areas more difficult to manage... fraud for one. It's cool and all, but it's a walled-enough-garden even without that constraint... a constraint that regulators, reinsurers, etc will find alien and confusing.
thanks, very good point. this is great feedback and a really valuable discussion for us. we need to have more experiments with decentralized applications and insurance markets to explore that. we are looking forward to address these questions with insurance and financial service providers.
it isn't yet. the current implementation relies on the flightstats API and oraclize.it to call the API from the contract. I think we are still far from truly decentralized applications, and it needs experiments like this to slowly get there. as a next step redundant data sources and oracles might help.
the total amount of payouts per flight is limited as well as premiums and individual payouts. there is a non-negligible legal risk of such action and the payout limits in the end will converge to the price of the risk someone is going to take.
The legal risk is zero for someone who is out of the jurisdiction of the US completely (eg in some developing country).
Ironically, your system is meant to help compensate people when delays to flights occur yet to me it looks like you've built something that strongly incentivises people to cause more disruption to flights.
Finding the right balance of incentives needs some trial and error. The discussions are not new and well known e.g. with generic prediction markets like Augur or Gnosis.
I think we will find a way to deal with those issues. Experiments like these will help us (and society in general) to come to the right conclusions. Of course we should be careful not to cause too much harm on the way.
also note that there is an easy workaround to limit this which essentially is the difference between a bet and an insurance: check if the user has a valid ticket for the flight.
I think the design space is much larger than what we have today, and blockchain applications surely have interesting features it might be worth exploring in that space.
airhelp is one of many services which deal with compensation claims which are mandated e.g. by EU regulation and take a good cut of the payout for trying to make a really cumbersome process less bad. the customer experience of claiming compensation is in my opinion much worse than a fully automated payout and the whole process a real pain for both customers and airlines.
I wonder how exactly it works. t0 are not very specific about implementation details. If they are using the bitcoin blockchain it should be possible to point out the actual transactions there.
Interesting thought but browsers should not interpret javascript inside an image. I would expect image rendering to be separated. Can someone with an expertise in browser design tell us how this actually works?
