People get touchy about the word "trust" in blockchain threads. Would it help if I said that the hardest part is creating a way to get the weather data on chain that the buyer and seller can agree on ahead of time?

Anyway, I'm obviously not claiming this can work without input from humans off chain. My point is that the infrastructure needed to get clean and honest weather data on to the chain (which requires human inputs) is much smaller than the entire infrastructure needed to administer weather insurance (which other than the previous part, can be done autonomously).

> Would it help if I said that the hardest part is creating a way to get the weather data on chain that the buyer and seller can agree on ahead of time?

> My point is that the infrastructure needed to get clean and honest weather data on to the chain (which requires human inputs) is much smaller than the entire infrastructure needed to administer weather insurance

Is "much smaller" infrastructure on a different dimension than the "hardest part" of the problem? If so, what dimensions are those?

If not, how can the trust/agreement part be both "much smaller" and also the "hardest", especially given that it requires human inputs, especially human driven systems for routinely validating the process (AKA audits), and adjudicating inevitable claims of breaches of the agreement (AKA the courts).

It's the hardest part compared to the rest of the blockchain solution. The "easy" onchain-only part replaces a vast amount of infrastructure that would exist in an insurance company.

>Would it help if I said that the hardest part is creating a way to get the weather data on chain that the buyer and seller can agree on ahead of time?

No, because it's still impossible to do that at scale without solving the oracle problem. Putting some arbitrary data on a chain doesn't mean the data is reliable.

I don't know if there's any way out of the oracle problem honestly. There's nothing wrong with shopping around between different human-administered oracles though, or having some code which polls multiple oracles and takes action based on some statistic applied to the oracles (mean, etc.) But yeah I'm not convinced the oracle problem can be solved.

Having multiple oracles doesn't really change the problem, then you're implicitly trusting a group of oracles instead of just one.

With multiple oracles and a statistic, you're trusting their results to be distributed along some distribution. But I'm being pedantic. Ultimately, yes, you are still trusting the oracles even if you aren't trusting them each in totality. Like I said I don't think there's a way out. Even if you hook up a weather sensor machine and push updates to the chain, even outside of malicious tampering, sensors themselves can be inaccurate or fail. Perhaps there's a case to be made for an autonomous weather sensor machine that is physically tamper-proof, but ultimately there's a certain amount of trust when dealing with off-chain data. I don't think that's able to be overcome.

You don't need to solve the oracle problem. Just agree on an oracle. Weather.com writing weather on chain could be your agreed upon solution, for example.

Oracles open up a whole giant industry of data middlemen, sounds great