@AssymetricInformation - uh, what? What I'm saying is that the trust in oracles should come from the community. You find 15 people who both you and the other person trust to not cheat, and use them as arbiters. The only "centralised" part here is oracles.li, which keeps the lists, but it's as central to the whole system as PirateBay is to BitTorrent. If it goes down, the contacts remain intact, the mirrors remain intact, and anyone can create yet another list of oracles without a help or need for oracles.li.


@Anotheranonlol - I haven't heard about CounterParty broadcast. Will check them out. Bitmessage is far from perfect

We just finished the first implementation of M of N oracles as explained in Orisi Whitepaper http://github.com/orisi/wiki/wiki/Orisi-White-Paper and in Gavin's bit-thereum post: http://gavintech.blogspot.com/2014/06/bit-thereum.html

The nodes' addresses and information is listed at http://oracles.li/

The oracles right now support just one command - a "timelock". It allows you to lock BTC funds on a multisig address for a period of time selected by you. The funds get unlocked only with both your signature, and signatures of above 51% of oracles you selected. Oracles will sign deliver their signatures once the time is up, and they have no way of running away with funds.

Here's the Orisi documentation https://github.com/orisi/orisi/blob/master/INSTALL.md.

You can set up your own oracle server node, or you can launch a client and perform a basic timelock transaction.

Other transaction kinds are coming soon - next week we'll probably have transactions depending on Bitstamp's BTCUSD price, and a generic mediation module depending on a word appearing on an url address (similar to http://earlytemple.com, but distributed)

@AssymetricInformation


That is actually quite easy. As all the signatures are public, you see who voted how. This is not a problem at all. The problem is that at every single moment, one oracle may be playing "long con", and delivering good results, waiting for that opportunity to strike big.

There is absolutely no way you can "trigger an audit" that would be meaningful in any way. Because all audits would show that the malicious oracles are working fine. Until one day all the oracles would decide to "take the money" and run.

What you're describing is a de facto proof of stake oracle system. And it's the one we started off with. The idea was for oracles to burn BTC to get into the line, to show that they are serious. Or to pay collateral.

The problem with such a solution is that you're beginning to sort oracles not by their trustworthiness, but by the amount of BTC they are willing to sacrifice when something goes wrong. This opens you up to a "simple" way of attacking. Say there's a line like the one you showed. The simple way of attacking is then for Evil Edmund to jump in and spend 3*28 BTC to get into the three cheapest above the line spots.
What Evil Edmund then does, is he silently signs up contracts that say "if it rains tomorrow on Sahara, you pay me 1BTC". With 150 random people. Every one of those random people sees that the network is being "protected" by 150 in collateral (3*28 Edmunds + O1 + O2), and thinks he's safe.

Edmund then performs a 51% attack, and votes that it's raining in Sahara. He takes the 150 BTC from random people, loses 3*28 of collateral, and he's on his way off. People lose a part of their money.

Of course, you could say that people should only protect up to the amount of collateral of the three "cheapest" oracles. That would cause additional problems:

- first of all, for anything but very short-term, it would provide too expensive (explained earlier in the thread). For short-term, why not. But by short term I mean "minutes", perhaps hours.
- who would you forward the disputes to? who judges that oracles really lied? another set of oracles?

So yeah - short term would work. Anything above a few hours, and you need to either introduce "partial reserve", where you allow the transactions protected by the system to be higher than collateral, or you need super-high fees. Because nobody will lock up 30 BTC in collateral to protect an arbitration for 30 BTC that lasts for half a year and gives him 10mBTC in profit.

Yeah, we discovered that a bit too late. Fortunately, 8 out of 15 go through Eligius, so there's that. I hope that once the system gets popular, we'll be able to convince miners to accept a higher number of signatures.

There are also some hacks that would might allow to map 40 oracles onto 15 signatures, but I really hope it won't come to that.


Yeah, we included that in the original whitepaper, in the section about "amendments". The highest risk - especially at the beginning - is really not trust, but the fact that operators will shut down their oracles. Once other ones realise one of them went offline for a longer period of time, they would sign a transaction transferring funds into an address with that oracle switched out for another one.

I think you may be right. When criticising collateral I considered only medium- and longterm contracts. In that case it would be too expensive to handle the collateral. But in the scenario you're talking about it might make sense.

If you want to build such an exchange, pm me - perhaps we can help some way.

News flash: we performed the first transaction settled by oracles yesterday - so the client is ready. We'll be setting up first official nodes today.

Happy ending - Gavin put up a link to our whitepaper at the end of the post

Now, back to work.

Well, if he knows of previous research in the area he should say so - even after the fact. Just like we're now telling everyone that realitykeys worked on very similar stuff before us.

@BitcoinDream: the concept is inspired by Ethereum, but it's not implemented in it - nor it can be in any blockchain currency really. Ethereum cannot reference outside world (e.g. track weather in Berlin to decide whether the contract goes through)

@edmundedgar: interesting insight, you're right. (edit: OTOH how many times did you hear about oracles being used as a way to implement sidechains functionality? before we posted about that? and gavin posted 3 hours later?)

Oh, didn't notice that, thanks. That's why I like to put things like this in open - perhaps someone will now come and say that we didn't invent the thing and it's we who should credit someone completely different

It's an open source software, there will be competition. And ultimately it really only matters who implements it.

I just think that unfair actions by community members should be published. Even if he thought of this first, it's unfair of him to not give us a credit afterward. So when someone sends me Gavin's blogpost again, I'll be directing people here.

Guys. We posted the whitepaper ( http://github.com/orisi/wiki/wiki/Orisi-White-Paper ) about distributed oracles monday morning u.s. time - as far as I know we were the first ones ever to publish more than a few sentences about the subject. Three hours later Gaving Andersen posted an article that explains a concept eerily similar to ours - bit-thereum ( http://gavintech.blogspot.com/2014/06/bit-thereum.html ).

I assumed that he didn't see our paper on /r/bitcoin, nor on bitcointalk before publishing his post. So I tweeted him info that this thing is already being implemented, and that there's a whole whitepaper on the subject. And e-mailed him. And sent a bitcointalk message. And someone posted a link to our paper in his blog comments. We got no reply from him, but perhaps he missed all of this.

So now when I explain Orisi project to people, some of them ask me "so, this is Gavin's idea, right?", and "is it like bit-thereum"? If I were a bigger person, I'd probably say: "who cares who's idea is it". But I'm not that great, so I'll just start forwarding people to this thread.

That was actually our original idea. We considered requiring oracles to burn some funds to prove that they are serious, or put up a collateral as you said.

First of all though, there's no real need for that. If oracle proves to not be trustworthy it will be thrown out, and will lose all the future profits. You could call this "an implicit collateral". If your oracle nets you 1BTC in fees per month, if you get thrown out, you'll effectively lose 10-50BTC you'd otherwise earn by running the oracle for the next 1-5 years.
But more importantly, a collateral would be extremely hard to track. Let's say that all the oracles.li oracles put up 100BTC in collateral. You want to sign a contract for 1BTC with Bob for a nice weather tomorrow, and you want to secure the contract with them. Are you safe to do so? Not necessarily. It could be that Bob already signed ten thousand contracts for 1BTC with other schmucks, and will bribe oracles to deliver a false verdict.
Ergo, a collateral doesn't really protect you unless you know how many contracts are being secured by it. And even then, it would probably ineffective to use X collateral to protect X in contracts, because oracles would need to require huge fees to earn their collateral back in any reasonable amount of time. So, you'd want X in collateral protecting 10*X in contracts - a "fractional reserve" you could say.

Is it doable? Well, perhaps. But I think a collateral of time spent setting up the oracle and building trust, and of future fees to be lost, should be good enough. I have no doubt that some oracles will lose the community - Mark Kerpeles, or PirateAt who had a large WoT score, or this guy who bet people 10kBTC that pirateAt will actually pay... But there chances that 20 of 40 oracles will do that at the same moment? Without their intent leaking out beforehand?

Besides that, you can have a set or Orisi nodes which you convince to set up a collateral fund, or burn money. And the market would decide whether it really matters that much.

There's a section on that in the Contract page in Bitcoin wiki: https://en.bitcoin.it/wiki/Contracts#Trust_minimization:_Amazon_AWS_oracles . I think the guys from bitsquare.io are working on that.

I think it's the matter of practicality for now. What kind of civil disputes would benefit from being mediated through blockchain? In most cases courts and existing arbitration companies do a good enough job.

As for the Sybil attack - MTurk workers' identities are verified by Amazon, so it's not that easy to perform such an attack. But yeah, it's the question of whether it's cheaper to have 10 super-verified super-secure oracles doing manual labour, or 1000 loosely verified people doing much a much simpler/dumber variant of labour.
Probably sometimes it will be one, sometimes it will be the other.

As for the debatability of the graphic design.. The program / questionnaire to MTurk workers will be known in advance. So, before contract signing, the designer will see all the rules: "1000 random dudes will have to say that colours are within lines, the picture is not stick figure, and that the picture is funny in scale from 1 to 10. Also, comics based on fart jokes will are to be given 0 points. If I get more than 5.0 in average, I'll get my money".

As for bets vs. contracts... I agree that there's a thin line between them. You could say to a freelancer: "I bet that you won't do this piece of software before a given deadline", but people often prefer to say: "Let's have a contract where I pay you if you do this before a deadline."
When you use "bet", it implies that gambling is involved. When you say "contract", it implies some kind of a deal between two parties, where both of them try to minimise the unknowns and they both expect the contract to pay unless something goes very very wrong.

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

I published a rather long article on the subject here:

http://orisi.net/discussion/4/mturk-and-distributed-oracles-two-tiered-arbitration

The general idea is that you could take an Mechanical Turk crowd wisdom and use it to deliver rulings in smart contracts. Thoughts?

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?"

hi everyone, oakpacific told me to drop by and talk about distributed oracles.

We just published this whitepaper a few hours ago
http://github.com/orisi/wiki/wiki/Orisi-White-Paper
and we'll have an implementation ready of it tomorrow.

The idea behind Orisi is that there can be a set of independent oracles locking the funds until some external condition occurs. So it's something similar to what you guys need to have done.

Perhaps you can get some cool things out of our whitepaper, or even fork our solution and just attach your verdict module?
Feel free to ask me any questions, although I'll be going to bed any moment now (Europe, midnight, long day)

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!

It's funny that we just published a whitepaper explaining the technical details of such a solution.

http://github.com/orisi/wiki/wiki/Orisi-White-Paper

There's also a basic implementation in the works, to be released today evening, or tomorrow.

Our team has been working on that for the past three weeks

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?