There is a kicker to both approaches as well - make Oracles deposit some amount as collateral. Use that then to run some form of insurance policy enforced via contracts, so that affected parties could be remedied.
Also I've been thinking about introducing civil disputes within the chain itself. Could that work? Or is that something that could easily be abused?
Topic: A practical distributed oracle system for cryptocurrency contracts. White Paper. - page 2. (Read 4332 times)
June 10, 2014, 07:34:03 PM
June 10, 2014, 06:39:06 PM
Hm, so it seems there are two possible approaches to the m of n oracle problem. Aside from the "who signs the keys" technicality.
One is that oracles promise to deliver as good results as possible. And you trust they will do so. (this is Reality Keys)
Another one is that oracles promise to run software and not interfere with it, and keep it secure - leaving the algorithm verification on the user's side. (this is Orisi as we described it in the paper, but perhaps we should change it?).
One is that oracles promise to deliver as good results as possible. And you trust they will do so. (this is Reality Keys)
Another one is that oracles promise to run software and not interfere with it, and keep it secure - leaving the algorithm verification on the user's side. (this is Orisi as we described it in the paper, but perhaps we should change it?).
Yup, that sounds right. The second approach reduces the amount you have to trust the oracle to be competent to do (as opposed to honest, where it doesn't help), since you can check the code they'll be running. It doesn't completely remove the need for competence because it's still possible to screw up the setup and operations, but the more completely you specify and automate the recommended setup and operations the closer you get to removing it.
What would make this approach really useful would be if there was a way to verify that the oracle really is running what they say they are. I've occasionally fruitlessly pestered cloud hosting providers to provide a service like this, where they'd give you a virtual machine that would only install the software you publicly specified, and would publish a record of what it was installing. Obviously this only shifts the need for trust along rather than getting rid of it, but cloud providers might be good people to shift the trust to because their businesses depend on strong existing reputations and they have a lot of skin in the game. The usefulness of this kind of service would go well beyond oracles - it would be useful for pretty much any case where you have some open source software that you need to run on a server and you need some kind of trust from your users.
As for the "who signs transactions" - I discussed it with the developers today. For now we want to wrap up the alpha / proof of concept where oracles are the ones doing the signing, so people can start playing with it as soon as possible.
But the concept of oracles just delivering the keys is very interesting. Aside from the legal stuff, it would make it easier to gather all the signatures (right now oracles have to send partially signed txs between them - it's a pain), and it would allow Orisi to easily interact with other systems. I'll get back to you via e-mail on this one, ok?
But the concept of oracles just delivering the keys is very interesting. Aside from the legal stuff, it would make it easier to gather all the signatures (right now oracles have to send partially signed txs between them - it's a pain), and it would allow Orisi to easily interact with other systems. I'll get back to you via e-mail on this one, ok?
Sounds good. I like this approach a lot but TBF there are some real practical advantages to signing the transactions:
1) People are more used to the signing model, and some clients can do it already without modification.
2) A lot of the patterns you need for the key-publishing model are either non-standard (so you have to send them to a miner like Eligius instead of broadcasting to the network) or need some rather unorthodox ECC voodoo to shoe-horn them into the standard script patterns, which makes me a little bit uncomfortable.
3) If you sign the transaction, you have more flexibility over what you sign, beyond what you could get into a bitcoin script. For example, you may want to say, "This transaction pays out (X * the BTC-USD) rate to Alice, and the rest to Bob". Whereas as far as I can figure conditions on the key-publishing model basically have to be binary.
June 10, 2014, 02:31:48 PM
Hm, so it seems there are two possible approaches to the m of n oracle problem. Aside from the "who signs the keys" technicality.
One is that oracles promise to deliver as good results as possible. And you trust they will do so. (this is Reality Keys)
Another one is that oracles promise to run software and not interfere with it, and keep it secure - leaving the algorithm verification on the user's side. (this is Orisi as we described it in the paper, but perhaps we should change it?).
^ just a random observation, not a critique of any approach.
As for the "who signs transactions" - I discussed it with the developers today. For now we want to wrap up the alpha / proof of concept where oracles are the ones doing the signing, so people can start playing with it as soon as possible.
But the concept of oracles just delivering the keys is very interesting. Aside from the legal stuff, it would make it easier to gather all the signatures (right now oracles have to send partially signed txs between them - it's a pain), and it would allow Orisi to easily interact with other systems. I'll get back to you via e-mail on this one, ok?
By the way, I just published this:
http://orisi.net/discussion/4/mturk-and-distributed-oracles-two-tiered-arbitration
Just some random thoughts - not sure how they fit the whole discussion we're having here. But we gave credit to RealityKeys in the article
One is that oracles promise to deliver as good results as possible. And you trust they will do so. (this is Reality Keys)
Another one is that oracles promise to run software and not interfere with it, and keep it secure - leaving the algorithm verification on the user's side. (this is Orisi as we described it in the paper, but perhaps we should change it?).
^ just a random observation, not a critique of any approach.
As for the "who signs transactions" - I discussed it with the developers today. For now we want to wrap up the alpha / proof of concept where oracles are the ones doing the signing, so people can start playing with it as soon as possible.
But the concept of oracles just delivering the keys is very interesting. Aside from the legal stuff, it would make it easier to gather all the signatures (right now oracles have to send partially signed txs between them - it's a pain), and it would allow Orisi to easily interact with other systems. I'll get back to you via e-mail on this one, ok?
By the way, I just published this:
http://orisi.net/discussion/4/mturk-and-distributed-oracles-two-tiered-arbitration
Just some random thoughts - not sure how they fit the whole discussion we're having here. But we gave credit to RealityKeys in the article
June 10, 2014, 05:47:31 AM
You could say that the debate is really: "Do I trust a single open-source software being run by independent rather trustworthy people, or a closed-source solution being run by a single rather trustworthy company? How much am I willing to pay for that trust?"
We need to distinguish between the ways we ultimately see people using this thing and what people are able to do right now.
The way we ultimately see it at Reality Keys the user (or their software) combines a bunch of competing "rather trustworthy" authorities of which we are only one, running different software implementations.
The way I think you see it the user (or their software) combines a bunch of competing "rather trustworthy" authorities, but all running your software implementation, or a variation of it.
To the extent that there's a difference, the former is slightly more decentralized than the latter, because there are more diverse software implementations. But naturally there are some substantial benefits to open source.
Then there's the question of what people can do right now, which is that in both cases you and I seem to be the only people running these services, so you just have to trust whichever you pick. But I'd imagine you'll be able to get other people to run nodes more quickly while we wait for our competitors to ship. I suspect the flip side of that will be that your nodes take a trustworthiness hit because the people running them have less skin in the game, but we'll see.
What would be particularly helpful here is if we can make it trivially easy to combine the two. If you're interested in adopting the "don't touch the contract" model where you just produce two public keys then one of the private keys, that would just be a matter of making sure our APIs can speak a common language. (Reality Keys probably won't start signing people's transactions for them any time soon, not least because it has some potential regulatory downsides that you don't need to worry about as much if you've got a bunch of guys running pseudonymous services over Tor etc.)
June 10, 2014, 03:13:19 AM
Edmund - yeah, we don't have tsunamis, but we have earthquakes here in Poland. Like one a year. 4-richter scale
As for arbiters just delivering the private keys (not signing the transaction like in Orisi) - I'm embarrassed to say that I didn't think of that before. It might be a better implementation, because right now all the oracles have to contact each other and send each other partially signed messages. We will definitely look into that.
As for many nodes going down at the same time - there is definitely such a risk with our system. We hide the nodes behind TOR and Bitmessage, and they will be distributed across various actors on various continents and various architectures. Still - someone might find an exploit within the way an Orisi node processes requests, or find a way to disrupt the BitMessage network. But isn't Bitcoin the same way really? It's a distributed system, but one that can be (and already was) brought down with a single core exploit.
@AssymetricInformation - I'm glad we moved the discussion off Twitter. It's a bit hard to explain things in 140 chars
As for a single person registering multiple nodes (i.e. a Sybil attack) - there will be short list of nodes - 20-40 position each. Those will be published on www.oracles.li, but also on other sites as well probably. The community will naturally verify that the list contains only nodes from independent parties, and complain if it's not the case. If the list administrator doesn't fix the list, people will create their own lists and the most trustworthy list will become a default choice with time. A similar approach is being used successfully in case of BitTorrent trackers.
Let's also not forget that the most traditional way of avoiding the Sybil attack is the good old identity checking. This is the way it is being done in ssl certificate verification, but also in courts all over the world - we know that judges are separate entities, and they stand a lot to lose if they decide to collude.
As for people wanting to become an Orisi oracle - we want this to be an process just as easy as setting up a Bitcoin node. You set up a virtual machine, and launch a script downloaded from repo. You don't have to track the sources yourself, you don't have to deliver arbitration by hand. Aside from occasional updates, it's supposed to be launch and forget really.
We expect the arbitration fees to be the equivalent of around USD$0.02 - if you decide to use 20 nodes, you'd have to pay $0.40+$0.10 Orisi project fee per verdict. If the default node list processes 10k verdicts a day, the people/companies running those nodes will get $100 per day. Not a fortune, but should be good enough for some people to bother doing that.
It's a different model from the Reality Keys, where the basic arbitration is free, but human intervention isn't. I think we may be targeting different markets really. In our case, you pay $0.50 to get a fully automated solution that's independent from a single company. In case of Reality Keys, you usually pay nothing, but have to trust a single provider to be still there when the time of resolution comes. You could say that the debate is really: "Do I trust a single open-source software being run by independent rather trustworthy people, or a closed-source solution being run by a single rather trustworthy company? How much am I willing to pay for that trust?"
As for arbiters just delivering the private keys (not signing the transaction like in Orisi) - I'm embarrassed to say that I didn't think of that before. It might be a better implementation, because right now all the oracles have to contact each other and send each other partially signed messages. We will definitely look into that.
As for many nodes going down at the same time - there is definitely such a risk with our system. We hide the nodes behind TOR and Bitmessage, and they will be distributed across various actors on various continents and various architectures. Still - someone might find an exploit within the way an Orisi node processes requests, or find a way to disrupt the BitMessage network. But isn't Bitcoin the same way really? It's a distributed system, but one that can be (and already was) brought down with a single core exploit.
@AssymetricInformation - I'm glad we moved the discussion off Twitter. It's a bit hard to explain things in 140 chars
As for a single person registering multiple nodes (i.e. a Sybil attack) - there will be short list of nodes - 20-40 position each. Those will be published on www.oracles.li, but also on other sites as well probably. The community will naturally verify that the list contains only nodes from independent parties, and complain if it's not the case. If the list administrator doesn't fix the list, people will create their own lists and the most trustworthy list will become a default choice with time. A similar approach is being used successfully in case of BitTorrent trackers.
Let's also not forget that the most traditional way of avoiding the Sybil attack is the good old identity checking. This is the way it is being done in ssl certificate verification, but also in courts all over the world - we know that judges are separate entities, and they stand a lot to lose if they decide to collude.
As for people wanting to become an Orisi oracle - we want this to be an process just as easy as setting up a Bitcoin node. You set up a virtual machine, and launch a script downloaded from repo. You don't have to track the sources yourself, you don't have to deliver arbitration by hand. Aside from occasional updates, it's supposed to be launch and forget really.
We expect the arbitration fees to be the equivalent of around USD$0.02 - if you decide to use 20 nodes, you'd have to pay $0.40+$0.10 Orisi project fee per verdict. If the default node list processes 10k verdicts a day, the people/companies running those nodes will get $100 per day. Not a fortune, but should be good enough for some people to bother doing that.
It's a different model from the Reality Keys, where the basic arbitration is free, but human intervention isn't. I think we may be targeting different markets really. In our case, you pay $0.50 to get a fully automated solution that's independent from a single company. In case of Reality Keys, you usually pay nothing, but have to trust a single provider to be still there when the time of resolution comes. You could say that the debate is really: "Do I trust a single open-source software being run by independent rather trustworthy people, or a closed-source solution being run by a single rather trustworthy company? How much am I willing to pay for that trust?"
June 10, 2014, 12:27:24 AM
Personally, (for what its worth) I also felt that this idea was more-similar to RealityKeys than you've described, and even though this was never explained to me, assumed that RealityKeys would be some kind of "gear" in a bigger mechanism (like a multisig 3 of 5). As I mentioned on twitter, trusting >1 oracles isn't as magically decentralized as one might hope, as someone can generate a number of fake identities and wait for an opportunity to strike.
One thing I like about RealityKeys (which makes it, currently, my favorite trusted-feed solution) is how their business model cleverly plays with the economics of trust (requesting a key is free [only efficient if this part is automated], but they 'charge' for the truth, aka independent verification, so the truth is what they need to focus on, but it is off-path so would never actually need to be used [unless project grows very large]). I haven't looked into it, but I'm skeptical that people will want to become a Orisi oracle and supply data. How much can they reasonably expect to be paid for this tedium?
I really like the idea of using Bitmessage to trigger oracles and am really excited for all of the new attention that this space is getting. I still think that I have the only truly trustless and decentralized solution, but that's far from saying that I believe my idea is going to be useful, let alone the most popular.
One thing I like about RealityKeys (which makes it, currently, my favorite trusted-feed solution) is how their business model cleverly plays with the economics of trust (requesting a key is free [only efficient if this part is automated], but they 'charge' for the truth, aka independent verification, so the truth is what they need to focus on, but it is off-path so would never actually need to be used [unless project grows very large]). I haven't looked into it, but I'm skeptical that people will want to become a Orisi oracle and supply data. How much can they reasonably expect to be paid for this tedium?
I really like the idea of using Bitmessage to trigger oracles and am really excited for all of the new attention that this space is getting. I still think that I have the only truly trustless and decentralized solution, but that's far from saying that I believe my idea is going to be useful, let alone the most popular.
June 09, 2014, 09:28:12 PM
Edmund Edgar from Reality Keys here.
This is an interesting piece of work. I think it's actually a bit less different from our approach than you're giving it credit for, because our service is designed to be combined with other authorities doing the same thing. It's entirely up to the parties whether they use a single service or a whole bunch of different ones and we aren't going to stop people who think a single authority is good enough for their purposes, but we certainly hadn't assumed that everybody would rely only on us.
We did consider open-sourcing our software to make it easy for other people to set this up. We may do this in future, but we figured the community is better served by multiple, separate implementations rather than everybody running the same code that ends up breaking in the same way. Redundancy is no use if all the redundant parts fail at the same time for the same reason, so when we're designing these systems the risks we need to worry about most are the ones that take out a critical number of "independent" nodes simultaneously. It's all very well having three separate external power lines and two underground generators cooling your nuclear reactor but it's still going to melt down if they all get taken out by the same tsunami.
PS. The other big tsunami risk we need to be worrying about here is regulatory.
This is an interesting piece of work. I think it's actually a bit less different from our approach than you're giving it credit for, because our service is designed to be combined with other authorities doing the same thing. It's entirely up to the parties whether they use a single service or a whole bunch of different ones and we aren't going to stop people who think a single authority is good enough for their purposes, but we certainly hadn't assumed that everybody would rely only on us.
We did consider open-sourcing our software to make it easy for other people to set this up. We may do this in future, but we figured the community is better served by multiple, separate implementations rather than everybody running the same code that ends up breaking in the same way. Redundancy is no use if all the redundant parts fail at the same time for the same reason, so when we're designing these systems the risks we need to worry about most are the ones that take out a critical number of "independent" nodes simultaneously. It's all very well having three separate external power lines and two underground generators cooling your nuclear reactor but it's still going to melt down if they all get taken out by the same tsunami.
PS. The other big tsunami risk we need to be worrying about here is regulatory.
June 09, 2014, 03:04:09 PM
Thanks for the kind words
Their approach is simpler than ours, but has two flaws. First of all - you have to trust them. While they look quite all secure, it would probably be unwise for you to build a big business based on such a single point of failure. Just like with exchanges - if their servers fail, if they go out of business, if they lose their keys... you'll also be lost.
In our case, if some oracles get disabled, hacked or go rogue, the other ones will be able to take over and continue. Assuming less than 50% of oracles die at the same time.
Also, let's say that you build a service that allows anonymous people to bet on weather. It's possible that one day a disgruntled employee of theirs will make a huge bet with your system and then introduce a "bug" into theirs. That's a big risk.
In our case, such a scenario is virtually impossible. There is no single person that can do such a thing - you'd have to convince the owners of a dozen other oracles to deliver a faulty result. That's not easy, especially if the oracles are being run by non-anonymous people.
The final issue with their solution is that it's limited in scope. While they offer a ton of facts to track - far more than our basic implementation available today - you cannot really do any more advanced tricks. For example - you cannot create a sidechain using their oracle, because they don't allow you to track alternative block chains. You cannot create a network of human arbiters. With our approach, the sky is the limit - you can fork Orisi and create your own arbitration software. There will still be an issue of finding trustworthy parties to run the oracles you devised, but perhaps we can help with that.
As for our faults compared to them:
- we're not yet production ready - alpha version of the client will be published today or tomorrow
- we're distributed only in theory - tomorrow we'll be having just three oracles running. but we hope to get community involved and get at least 20-40 of them being ran by trustworthy individuals
- the datasources we offer are very scarce - by the end of the week we'll have just a bitcoin price ticker, and a basic website parser - so you'll be able to get verdicts based on bitcoin price or on a website containing certain words. on the other hand, as I said, anyone can fork us and implement whatever crazy things they want
- they work with Ethereum and any other cryptocurrency, we only work with Bitcoin for now. Although we hope to get Ethereum support quite soon.
In other words - they are e-gold (centralised, closed), we're bitcoin (distributed, open source). Of course, our software is not yet polished and not yet production ready, but as the time goes, a distributed set of oracles will allow for things and security that you could never get with a single oracle.
I'm sorry if it sounds like I'm bashing them. I try to always speak in positives, but it's just that distributed oracles are really so much better I'll forward this discussion to them, perhaps we can have an interesting argumentation!
Their approach is simpler than ours, but has two flaws. First of all - you have to trust them. While they look quite all secure, it would probably be unwise for you to build a big business based on such a single point of failure. Just like with exchanges - if their servers fail, if they go out of business, if they lose their keys... you'll also be lost.
In our case, if some oracles get disabled, hacked or go rogue, the other ones will be able to take over and continue. Assuming less than 50% of oracles die at the same time.
Also, let's say that you build a service that allows anonymous people to bet on weather. It's possible that one day a disgruntled employee of theirs will make a huge bet with your system and then introduce a "bug" into theirs. That's a big risk.
In our case, such a scenario is virtually impossible. There is no single person that can do such a thing - you'd have to convince the owners of a dozen other oracles to deliver a faulty result. That's not easy, especially if the oracles are being run by non-anonymous people.
The final issue with their solution is that it's limited in scope. While they offer a ton of facts to track - far more than our basic implementation available today - you cannot really do any more advanced tricks. For example - you cannot create a sidechain using their oracle, because they don't allow you to track alternative block chains. You cannot create a network of human arbiters. With our approach, the sky is the limit - you can fork Orisi and create your own arbitration software. There will still be an issue of finding trustworthy parties to run the oracles you devised, but perhaps we can help with that.
As for our faults compared to them:
- we're not yet production ready - alpha version of the client will be published today or tomorrow
- we're distributed only in theory - tomorrow we'll be having just three oracles running. but we hope to get community involved and get at least 20-40 of them being ran by trustworthy individuals
- the datasources we offer are very scarce - by the end of the week we'll have just a bitcoin price ticker, and a basic website parser - so you'll be able to get verdicts based on bitcoin price or on a website containing certain words. on the other hand, as I said, anyone can fork us and implement whatever crazy things they want
- they work with Ethereum and any other cryptocurrency, we only work with Bitcoin for now. Although we hope to get Ethereum support quite soon.
In other words - they are e-gold (centralised, closed), we're bitcoin (distributed, open source). Of course, our software is not yet polished and not yet production ready, but as the time goes, a distributed set of oracles will allow for things and security that you could never get with a single oracle.
I'm sorry if it sounds like I'm bashing them. I try to always speak in positives, but it's just that distributed oracles are really so much better
I'll forward this discussion to them, perhaps we can have an interesting argumentation! June 09, 2014, 02:03:40 PM
I like the project. I wish you success getting off the ground. Kudos for using Bitmessage to prevent DDOS of oracle nodes.
For the sake of starting a discussion, could you break down in a nutshell how this project is superior/inferior to what https://www.realitykeys.com does?
For the sake of starting a discussion, could you break down in a nutshell how this project is superior/inferior to what https://www.realitykeys.com does?
June 09, 2014, 09:40:24 AM
Just published this whitepaper:
https://github.com/orisi/wiki/wiki/Orisi-White-Paper
It's about an implementation of a distributed oracle system. The idea is that for contracts that require external input, we may set up a set of oracles that monitor the external world and sign transactions using m of n signatures. So, instead of trusting just one oracle/arbiter to deliver the verdict, you're trusting 20-40 ones, run by trustworthy individuals who are unlikely to cheat.
Using Orisi debs will soon be able to implement cool things like:
- contracts depending on btc price, weather and so on
- human contract arbitration
- additional protection of bitcoin wallets
- sidechains - even with all the current bitcoind version
We're also wrapping up an implementation of such a system, and will be launching first oracles within the network later on today, or tomorrow.
Any feedback?
https://github.com/orisi/wiki/wiki/Orisi-White-Paper
It's about an implementation of a distributed oracle system. The idea is that for contracts that require external input, we may set up a set of oracles that monitor the external world and sign transactions using m of n signatures. So, instead of trusting just one oracle/arbiter to deliver the verdict, you're trusting 20-40 ones, run by trustworthy individuals who are unlikely to cheat.
Using Orisi debs will soon be able to implement cool things like:
- contracts depending on btc price, weather and so on
- human contract arbitration
- additional protection of bitcoin wallets
- sidechains - even with all the current bitcoind version
We're also wrapping up an implementation of such a system, and will be launching first oracles within the network later on today, or tomorrow.
Any feedback?
Jump to: