Game Theory, Assurance Contracts, and Crowdfunding with Bitcoin
Posted on April 28, 2014
One of my majors in college was international politics, and among the course requirements were a number of classes on game theory. It was one of the most interesting parts of my coursework, but I am sure I wouldn’t have believed it if I’d been told that a few years later I’d be spending an afternoon, of my own volition, writing about using the Bitcoin protocol to create assurance contracts.
The free rider problem in game theory posits that there are situations in which the creation of a public good (for example, building a road) will provide utility to a group of people and leave everyone better off. However, if there is no way of excluding those who did not contribute, many will make the rational decision to not pay and yet still reap the benefits of others’ contributions. In some cases this means that the public good will not be created, and utility is lower for everyone. Assurance contracts represent a way of solving the issue by ensuring that people actually contribute. In one of these binding contracts, a group of people agrees to fund a certain public good when a financial threshold is met. If the project is fully funded, the public good is provided, and if it is not, then the money is returned to those who pledged it.
Another interesting twist is the ability to create dominant assurance contracts. In game theory, a dominant strategy is one that is the best course of action regardless of what the other actors in a scenario do. In an assurance contract situation, a dominant strategy would involve having the entrepreneur agree to pay a certain amount of money back to the contributors in the event the project wasn’t funded. Although this increases the risk for the entrepreneur, it also increases the probability the project will be funded. For the potential contributors, this setup ensures a win-win situation, where funding the project is always the best strategy – they either get the good, or their money back plus some. I won’t go into great depth about creating dominant assurance contracts with Bitcoin here, but if you’re interested here’s a solid explanation.
The binding nature of the assurance contract dictates that there must actually be someone enforcing it. This has historically been a third party like a government, a mediator, an escrow service, etc. Reliance on a third party can be problematic in a number of ways, among which the fact that there’s not necessarily a way to ensure they will operate fairly. In international scenarios involving multiple countries trusting one another, there’s no greater power who can offer that assurance. (The UN was supposed to offer this, but sadly it holds very little real power – consider that in 2010 for instance, only 13 of 193 countries paid their dues on time, and the US itself owed roughly $1.2 billion in arrears.) In situations like this, having an independent arbiter would be key — and better yet one that is not corruptible and technology rather than human-based. Enter the Bitcoin protocol.
The basis of crowdfunding platforms like Kickstarter and Indiegogo is the same – they operate as the third party who collects funds from backers and then releases money to the project creator when the threshold is met. With Bitcoin, the need for a third party is removed and the process can be handled by the technology.
Here’s how it would work:
- Alice, an entrepreneur, decides to fundraise for the launch of her new product. She announces that the good will be produced if she can raise 100 BTC, and opens up contributions to anyone. She also creates a new address.
- Everyone who wants to contribute creates a new transaction that spends whatever amount they are pledging to the address Alice provided. They don’t broadcast the transaction. There are a few key differences from a regular transaction: A) Contributors can’t have any change. If they don’t have an address with an output of the right amount, they can create a new one by spending money to one of their own addresses. B) The input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. C) The output value is set to 100 BTC, which is the funding threshold set by Alice.
- The transaction is uploaded to Alice’s server, which saves it to disk. It keeps a count of how many bitcoins have been pledged.
- When the funding threshold is met, the server merges the individual transactions into a single new one with only one output. That output is then spendable to the address Alice created, and the inputs are collected from the contributors. Earlier, the transaction was not valid and couldn’t be completed, because the inputs did not match the output. When total contributions reach the 100 BTC threshold, inputs match outputs, and the transaction becomes valid.
- The final transaction is broadcast to the network, sending the contributions to Alice’s address.
The Bitcoin protocol has several properties which make it perfect for crowdfunding and render the above steps possible.
- The fact that the transaction is not valid if inputs do not match output means that Alice cannot spend the bitcoins she receives until the threshold is met. This ensures that contributors can send her a pledge safely, knowing that it can only be spent when the total project is funded.
- SIGHASH_ALL means that every part of the transaction is signed with the exception of the input scripts. This is important as it allows the inputs to change (as occurs every time a new contribution is added) without breaking the transaction. If the outputs change, however, the transaction does break. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in – the other inputs are not signed and thus can be anything.
**One thing to be aware of is that the transaction isn’t actually spent until the total threshold is met, so contributors have to be careful not to forget about it and accidentally spend the same transaction twice.
Applying the Bitcoin protocol to assurance contracts and crowdfunding allows us to abstract to technology what could be a very manual process of collecting funds. It removes the roadblock of finding a shared, trusted third party arbiter, which can be particularly difficult – if not impossible – in tense international scenarios, and undesirable in other cases as well. The most incredible thing about it is the enormous range of instances in which it can be used – literally from raising money for a third grade field trip to accepting international contributions to build a refugee camp in a war-torn region. I’d say that’s some legitimate added value — not bad for fake internet money!