We just published this whitepaper:
https://github.com/orisi/wiki/wiki/Orisi-White-PaperIt's about a solution to the problem of tying contracts with outside world. Right now there's no good way to do so - Ethereum blockchain obviously will not fetch a website to decide if an outcome happened, and Shellingcoins have a ton of practical difficulties.
What we're proposing is a network of independent arbiters who monitor the world and sign transactions as necessary.
It currently supports only Bitcoin, but was made with Ethereum in mind - perhaps somebody would like to help us port it?
The source code for distributed oracles & clients will be published today afternoon, and there's a website (
http://oracles.li/ ) that goes along with it.
Thoughts?
Comments
1) To prevent collusion (which is another problem as opposed to bribes), the system should randomly assign oracles. Potentially, as a second check, the oracles should not have any prior relationship with one another (this will prevent a core group of oracles from consolidating power).
2) The number of oracle for a particular contract should be able to be set by the parties. However, a default number of oracles assigned by the system could be useful. For example, juries in the United States generally have anywhere between 7 and 12 people. The reason being -- it ideally prevents the risk of group think and bias (whether that in fact happens is a subject of vigorous debate). Another point to consider, most large private arbitrations require three judges to make a decision (one appointed by each side and one neutral) for much the same reason.
I would love to help out more with this project.
Wetplant. Thanks for the points.
As for 1) - it's totally doable within this system. What we propose in the whitepaper is that Alice and Bob choose the list of oracles delivered from the secure party / oracles.li. But one could easily extend the idea to say: "Alice and Bob will throw satoshi-dice to choose a list of 20 out of 400 oracles from a commonly trusted list".
This approach still often wouldn't prevent collusion though - Bob could introduce 11 collated oracles into the list of 400, and wait for a contract that happens to choose them at random. Then cheat.
What really protects us from collusion is still the fact that parties are well known and respectable. And the fact that they stand to lose a lot from being removed from the list. The shorter the list, the more they stand to lose. It's one thing if I get asked for a verdict once in a year (because I'm one in 10 thousand) and get removed from the list, and another thing if half of the global market is asking me daily for a verdict and I earn a fortune on fees.
So personally, if I were Alice or Bob, I would prefer a short and settled upon a list of oracles that are well verified by the community. But if someone wants to extend the client to implement the random oracle choosing, it would work quite well and we'll be glad to help.
2) This will definitely be done. The idea is that oracles.li will contain various lists. The "default" being between 20 and 40 positions, but other lists containing different number and kinds of nodes. I imagine there being a list of Ethereum-specific oracles, or a short list of 5 uber-secure oracles, or a list of 400 more-or-less trusted oracles to be used as a random seed for what you proposed in 1).
The reason I think 20-40 nodes will be better than 7-12 (as in US supreme court) is that nodes are software. Software gets lost and disabled. Once a node is disabled it's unable to deliver it's signature. So if you only use 7 nodes, and 4 of them happen to die between contract signing and contract resolution, your funds will get locked.
We have a theoretical way to prevent that (see "amendments" position in the roadmap), but still, 7 to 11 nodes may not be enough. On the other way, anything above 40 nodes will be tough to implement due to a nature of the way multisig is implemented in bitcoin.
But again, as I said - there definitely will be more than one set of nodes
Any specific way you would be willing help? We could use help with node development, sysops, building services on top of that, and just spreading the word. We also wouldn't mind someone helping with Ethereum support development. And of course running the nodes
I think the real power in the system would be to make it possible for oracles to be human beings, who can build a reputation based on some formula. (let's say, hypothetically, each human oracle was assigned a rating of 1-10 based on some formula to prevent gaming and encourage recent participation).
There are many contracts that cannot be decided just by computers or just trusted feed sources. If you layer in human arbitrators into smart contracts, then you could potentially decentralize huge swaths of the judiciary and transform law into a service. This would have as big an impact on the world has a trusted decentralized currency. It would enable people in corrupt and less developed portions of the world to actually do business and help each other succeed without the need for their governments.
I can help in a number of different ways both strategically and practically. I am a lawyer, who has sold an internet company in the past. I also understand how people enter into a decide disputes in the real world. I am interested in building a service on top of Orisi or another similar protocol. I have been building a decentralized judiciary outside of the cryptocurrency space for the past several months, but am interested in extending the application using projects like Ethereum.
Hm. It's an interesting concept. Instead of having a default list on orisi.li, of very secure and very trusted nodes, we could have a list of 10k nodes with moderately verified identities (e.g. by Facebook/Twitter login, reddit karma, or WoT score). And then, for each transaction, choose just 20 nodes from that list.
For now, the default short list is much easier to implement, but I'll add your concept to the whitepaper
> There are many contracts that cannot be decided just by computers or just trusted feed sources.
Did you see our article on MTurk and oracles?
http://orisi.net/discussion/4/mturk-and-distributed-oracles-two-tiered-arbitration
> I can help in a number of different ways both strategically and practically.
On this, I'd get back to you next week, ok?
Yes, I saw the post. I agree that turk can be useful. But, I think that limits the application to simple disputes. To handle the hard contracts, the big dollar contracts, and serious issues, you need a decentralized group of people that have been distilled as trusted oracles.
If you develop a protocol and procedure to handle the later, it will undoubtedly change the world.
With 20-40 oracles, we can expect the comminty to look through the list occasionally. Above 40 oracles? I have absolutely no idea.
If you want to make an impact, the service needs to be able to scale. You can't scale with 20/40 oracles. There's too many problems in the world for 20 to 40 people to handle.