4meta5
commented
5 years ago So, one rough idea would be to use the blockchain as a registry for packages that are insured by software providers (or anyone).
To add the package to the registry, the author might need to get audits to convince investors to post collateral that testifies to the security of a specific build/version. This adds legitimacy to the registry in a way that hasn't been possible before in the sense that the packages are insured against specific negative outcomes pertaining to the package's usage. The investors that insure the package receive cash flows in proportion to the relative quantity of insurance purchased by users and/or speculators that expect a security breach to ensue.
In the event of a security breach (defined more explicitly below), the insurer's collateral is slashed and distributed to the stakeholders that bought insurance (likely because they are using the package and want to hedge financial losses that could come with a hack, but buyers could also just be speculators that think the package will get hacked).
So, the basic set up is to design a market around which participants vote on whether or not a package will be hacked within a specific timeframe. I think this could be modeled as a prediction market (on whether the package is hacked within a specific time period).
This could be extended so that some users are automatically granted insurance to reassure usage of alpha software. The counterparty in this scenario would probably be whoever is publishing the package (it could signal to the user that the provider is confident about the security of the application).
If you take a step back, you can also see this environment fostering clever new licensing agreements for software. We could design licenses that are granted on a per-user basis with insurance guarantees for up to a certain amount lost. Audits could also be coordinated on the platform and come with a similar insurance guarantee.
This is reminiscent of how the US insures FDIC insured banks for up to a certain amount of money per person. Likewise, we could have an organization that insures quality software builds up to a certain amount of money per person. This entity would collect the insurance premiums paid by those that purchase the insurance (so it would generate revenue if users buy insurance).
In general, it may be useful to forgot what we already know about how licensing and OSS works to imagine less restrictive models for trading builds. The hard part is enforcing scarcity, but this isn't necessary if we trade insurance on builds rather than the builds themselves. Even so, there needs to be a market for insuring for/against these builds and making such a market might be difficult given that this is so far from what people are comfortable with...
Security Breach Definition (and verification in general)
The definition of a security breach is subjective and hard to explicitly define. The insurance could come with conditions such that it is determined that n experts that would vote in the case of a challenge on whether or not the security was breached as well as the magnitude of impact. So, we delegate dispute resolution for whether or not security was breached (=> insurance is due) to a group of experts that are defined before the insurance is issued. Choosing which members vote in each challenge could use a similar random sampling via VRF pattern that is used for substituter sampling.
dvc94ch
@4meta5 can you elaborate on what you mean by insurance market?