As we've been developing the concept, it's become apparent that we need to solve a more fundamental problem first: how to achieve contract recourse and dispute resolution in a decentralized environment. Here's the basic outline of how we will implement such a system. If you are interested in helping to develop these ideas, please create an account on the collaboration site and post your thoughts there:
http://praesto.airdns.org:63853/projects/1/wiki/Insurancehttp://nkou33nmqzfpqw2a.onion/projects/1/wiki/Insurancehttp://wp6qoxbb6hjxs32ih7zur3d3bbjtyazea4gc4hhfcrff2mhlxyva.b32.i2p/projects/1/wiki/InsuranceContract enforcement and dispute resolution
The problem
Decentralized virtual currencies make it possible for people all over the world to exchange payments without any of the delay, cost, or friction normally associated with international money transfers. This new capability opens up huge possibilities for trade that never existed before, but those new possibilities bring with them the same old risks of contract disputes, and the international nature of the deals means that the typical venues for resolving disputes and collecting damages, government court systems, are not available for anyone except the wealthiest actors.
In addition to this, decentralized virtual currencies enable commerce that is forbidden by repressive governments in various parts of the world, and people working in those industries can't access the court system for their business even when all parties are operating in the same legal jurisdiction.
In order for the economy made possible by decentralized digital currencies to achieve its full potential, we need to build a system of decentralized, digital, contract enforcement and dispute resolution mechanisms that operate as frictionlessly, and as borderlessly, and as independently from legacy systems, as the currencies themselves.
The model
In a business transaction where parties might reside in different countries and one or more is anonymous, the traditional paradigm of legal enforcement is impossible. The only model that makes sense then, is one of restitution, via funds which have been place in the custody of a trusted third party prior to the initiation of a transaction. This concept is known as "surety", but since few readers are familiar with that term we'll call it "insurance" in this document.
Two people who want to have recourse in the event their deal goes bad will require the other person to provide a proof of insurance associated with that deal. This proof assures the other person that in the event a dispute arises, sufficient funds are provably available to cover damages.
In this model, insurance companies act as bridges between Bitcoin and Open Transactions. Bitcoin deposits serve as the funds being held in escrow, and the insurance companies issue OT assets and smart contracts to facilitate their customers' business deals. In the event they need to pay out a claim, they deliver bitcoins from their escrowed funds to the claimant.
Insurance companies
An insurance company is any group of people who agree to act as trustees and arbiters, generate the correct cryptographic key pairs for Bitcoin and OT, and advertise their services. Forming and operating an insurance company is entirely peer-to-peer, with no need to operate servers or run special software besides the standard OT client.
The company first needs to decide on their list of members and their consensus parameters. For example, a group of five friends may decide to operate as a 3-of-5 company. An insurance company will generally want to require a majority vote on all operations, and their customers will almost certainly demand it. On the other hand, if they set the required consensus too high, the become vulnerable to having all their funds become undependable and businesses to grind to a halt of one member loses their key pairs, or gets hit by a bus. Once these parameters have been chosen, they won't be able to change them later.
Once the members all agree to form a company, their clients generate BIP32 keys for creating bitcoin addresses. The company accepts deposits to P2SH addresses where the hashed output script is a m-of-n muiltsig. The use of BIP32 allows the company to generate unique P2SH addresses for individual customer deposits without requiring any further key exchange. All OT assets which the company issues will reference specific unspent outputs, which the company can prove their ownership over using the appropriate public keys.
At the same time, the company creates a nym with the same multisig parameters to use for issuing assets and smart contracts.
Operation of the company happens in the following phases:
Accepting deposits
The insurance company forms a smart contract with their customer.
The customer deposits bitcoins to the P2SH address specified in the contract.
Once the bitcoin arrive, the insurance company issues bitcoin-denominated OT assets to the customer nym specified in the contract, for later use in purchasing insurance coverage for a specific deal.
Insuring contracts
When a customer enters into a deal with another party who requires insurance, the customer initiates a three-way smart contract between their insurance company, themselves, and the other party. The customer must deposit bitcoins (bitcoin-denominated OT assets) sufficient to cover the amount of the insurance and pay the per-contract fee their insurance company requires. The smart contract specifies the conditions under which the escrowed bitcoins are returned to the customer, and under which conditions they are paid out to the other party.
This contract is then attached to the deal being insured as a subcontract.
It's likely that in many cases all parties will require insurance. It's also likely that each one might be using a different insurance company to cover their respective ends of the deal.
Resolving disputes
In the event one party is unsatisfied with the performance of the other party, they file a dispute by activating the insurance subcontract they hold from the person they wish to recover from. At this point, the members of the insurance company will collect evidence and vote on a resolution.
The insurance company advertises up front how the depth of the adjudication they provide and this is reflected in their fees. The least expensive companies will allow one statement from each party, deliberate briefly (or not at all) and vote immediately. The companies willing to perform independent investigations, allow cross examinations, and other expensive operations will charge more for their services. This will allow users of these companies to get the best price for exactly the the amount of protection they desire for a given deal.
Returning deposits
Customers who no longer desire insurance from the company, can redeem their escrowed bitcoins by returning the OT assets back to the issuer.
The chicken and the egg
One of the largest problems this model presents is the risk of the insurance company stealing deposits or otherwise failing to meet their obligations.
Remember that before they accept customer deposits, the first thing an insurance company does is form a smart contract with their customer. Naturally, then, the way to protect the user from misbehaviour by the insurance company is for that contract to also be insured by a different insurance company.
With this in mind, the first step in forming an insurance company must be "buy insurance equal to the value of customer deposits you wish to accept".
How, then, can the first insurance company form?
The best solution is to bootstrap the insurance ecosystem by starting with three identical companies: A, B, and C.
A deposits their bond funds to buy insurance from B, via a revisable insurance contract that does not initially require B to insure their side of the deal (since they don't have anyone to buy it from yet).
C purchases insurance from A, with A's part of the contract insured by B.
B purchases insurance from C, with C's part of the contract insured by A.
Now that B has insurance available, A and B can revise their original contract to include it.
At this point, we've bootstrapped an initial set of insurance companies who can insure new entrants into the ecosystem, without creating any single entity who can cheat or any perverse incentives to collaborate in order to cheat.
Full reserve insurance
Using this system, it is not possible for insurance companies to lie about their reserves, since that information is available on the blockchain and protected on the OT side by real time auditing.
It's also not possible for any customer to lie about their insurance coverage, for example by pledging the same assets as collateral for more than one deal at the same time, because the insurance smart contract contains the actual OT assets.
Growth
An insurance company is limited in their ability to insure based on how much of their own capital they can use to purchase insurance. This will result in two things: first, since no single company has an unlimited capability to accept new customers there will be a demand for more insurance companies. Secondly, insurance companies will have an incentive to reinvest all or part of their fee revenue back into their own insurance bond in order to grow their ability to insure.
Another factor affecting their growth will be the purchasing power of their escrowed funds. As the purchasing power of bitcoin increases, the value of their bonds increases accordingly and they can cover higher valued deals.
Private law
Insurance companies will advertise their services to a distributed database that OT clients can query in order to help users find an suitable provider.
Part of this advertisement, and the subsequent contracts the company forms, will be type of dispute resolution the company offers, especially the legal theories they operate under.
Company A might choose to base their decisions on interpretations of Common Law, and company B might choose to apply Sharia, while company C enforces Klingon law.
Individual users can choose what type of legal code to operate under when creating their contracts, with the OT client software automatically suggesting providers for their deals based on the preferences they have indicated.
