Topic: A practical distributed oracle system for cryptocurrency contracts. White Paper. (Read 4331 times)

Just published a khan-academy style explaination of how we handle a timelock transaction:

https://www.youtube.com/watch?v=boPW1FwNu4c

And here's a tutorial for whoever wants to set up a transaction by himself/herself:

https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction

Regarding the compressed keys that should make the transaction standard. Did you test that, Edmund? We're compressing the keys, but tx is still too big to be accepted by anything besides Eligius.

That assumes that you know is in advance either the receiver's key, or receiver's address. There are contracts that say: "The first person to perform X will receive bitcoins protected by oracles".

That's not how you do them. You combine the hash with private key of the party so you can redeem with "(Alice-priv + data-hashing-to-yes-hash) OR (Bob-priv + data-hashing-to-no-hash)".


Yes, there are some scenarios that require oracles to sign.

Yeah, on the other hand, the problem with hashes is that they are "all or nothing", and they don't really allow for locking in the output address.

The no output address lock is problematic, because there's of an obvious attack vector. I lock in my funds on an address protected by a hash. Once I want to redeem them, I publish a transaction, and a potential attacker can grab my transaction, replace the address with his, and try to race me to miners.
The issue can be solved, and such an attack is hard to pull off, but still - a threat.

But the bigger issue is that "all or nothing". We have contracts in the pipeline that will withdraw only a part of money from a multisig. For example, in case when you want to use oracles to handle a trusted wallet system (where oracles allow you to withdraw only a part of money per given day), or for term contracts, where the receiver gets from 0 to X bitcoins depending on details of the condition (e.g. he's to receive an equivalent of USD$1000, and the rest should go to the sender).
Or a scenario where oracles are used to build a distributed mixer - everyone puts in money into a multisig address, and at a later date withdraws that money. (btw. if there's anyone willing to do a mixer, or a trusted wallet, or term contracts, contact me at [email protected], we'll help you do that using Orisi).

There are ways to mitigate "all or nothing", but not in all scenarios (not in the mixer scenario), and in other scenarios it's quite problematic (you'd have to create multiple multisig addresses holding various denominations).

I don't know any more than anyone else does from watching the mailing list and I don't know of an ETA but assuming nobody disagrees I'd guess it would be in the next minor release. Maybe a few months until then? It'll still be a while before most miners upgrade after that but I don't think you need a lot of uptake to get something relayed?

As for the current rules, make sure you're compressing your keys and including a sufficient fee for the transaction size. IIUC you should currently be able to do 15 on the current network without becoming non-standard. I doubt that will be increased any time soon because signature operations are expensive and potentially cause DoS risk.

You may be able to cram more authorities in by using hash locking instead of signing. Instead of doing what Reality Keys currently does and saying, "I will release the privkey to pubkey Y if X happens" the oracle says, I will release the string that hashes to hash Y if X happens". Hashes should be shorter, and avoid using up sigops.

The benefits of keys over hashes are:
1) They can be combined with other keys using ECC maths to get through the standard checks. (Hopefully soon moot)
2) They can be similarly combined with keys held only by the parties for privacy.
3) You can use the built in m of n logic without having to script it.

I am also interested in applying this into BetMoose.

(We really don't want to be holding coin)

Following this closely. PM me if anyone has merging ideas with our platform.

Adam

Wow, this is great news for smart contracts altogether. Do you know when it will get pulled, and what's the e.t.a. on this reaching the stable bitcoind release?

Even with this update though, there's a problem with transaction size, right? IIRC we had problems submitting anything above 3 of 3 sig to pools other than Eligius due to the transaction size exceeding 500 bytes.

A quick update to this: Gavin has written a pull request that will make the transactions that allow you to do the key-issuing model cleanly standard. Assuming this gets pulled, it makes this model very attractive compared to transaction-signing. It's clear, transparent, involves oracles in less potentially regulated activity and gets rid of all kinds of coordination headaches. It also makes the oracles compatible with other systems to bitcoin, which they don't even have to know about. Just issue keys and let the client deal with the signing. The oracle doesn't need to know anything about the transaction, or about other oracles. I would strongly advise anyone thinking of running an oracle to look at this model.

@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

kolinko: Are you trolling me with such a bad answer? Surely you aren't saying that, for every contract, you personally will look at how people signed to make sure that they signed correctly, then yourself provide a final signature. The challenge is to do this decentralized. Welcome to square 1??

is it not possible for you to use something like CounterParty broadcasts
Instead of bitmessage?

@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.

It's not always possible. In effect that's why you have Oracles, to produce decentralized consensus, where it is not possible to enforce through the block-chain.

If we assume that Oracles will never collude and take over 51%, it is possible to have other Oracles verify the data and slap the bad ones on the wrist.

However with your idea of randomizing and redistributing ownership, this might get even more stable.

Also if you consider that the position for an Oracle is a perpetual auction, you could have the ones waiting in line spank the bad ones as well.

Say you have 5 active oracles at a time (for simplicity only) and you sort them by the total they have deposited as collateral:

O1 | 35 BTC
O2 | 31 BTC
O3 | 27 BTC
O4 | 23 BTC
O5 | 16 BTC
------------- <-- CUT OFF NEXT GUYS ARE WAITING IN LINE TO TAKE THE POSITION AND COULD ALSO PLAY POLICE
O6 | 12 BTC
O7 | 11 BTC

etc.

So let's say O1 and O2 collude and O1 does something bad - then there is the court I mentioned, it gets decided in an off-the record chain, until a verdict is reached.
O3,O4,O5 can verify the same data and decide oh hell no O1 and O2 are lying - kick them out.


Scenario 2 which might even solve the 51%:

Once there is a problem detected by a single Oracle, say O7 detects O1 is being a bad actor, he starts investigation. Let's say during the investigation O2 and O3 collude and defend O1.
Since the oracles in line will also be allowed to vote, they may get the truth correctly even when 51% of the active oracles are colluding.

I will admit I don't have a concrete system that works, just random bits and pieces of the puzzle.

I think there is a way to make this work, but so far none of this is elegant and to my liking.

I think about this all the time, trying to get it to work, but actually it doesn't make any sense at all!

This idea implies that if the Oracle misbehaves, they'll lose some collateral. But how do you ever know that the Oracle misbehaved? My solution, to use a simultaneous coordination game, and redistribute ownership, is actually a pretty weak solution, but it really is the only solution I've come across (aside from the similar and non-scalable Baysian Truth Serum). Its the only thing that provides any reliable meta-information for assessing honesty.

The only way this could make sense would be to have a separate mechanism, with a greater emphasis on accuracy and less of an emphasis cost (speed, effort, employed-capital). If someone has one, but more importantly, a way of triggering it, I'd like to hear it. The tricky part is that if the cost to triggering an audit is too low, people will trigger audits all the time, to attack the network (ie it might make attacking easier), and if it is too high, it actually encourages attacks or and make threats-to-attack more credible. Its the same problem as before: what costs more for the attacker?

I invite you all to read this section of my FAQ, which discusses incentive-systems: https://github.com/psztorc/Truthcoin/tree/master/docs#why-dont-you

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.

There are use cases where putting down a collateral actually makes perfect sense and is easy to track/reimburse.

Allow me to elaborate. I was considering using that for a coin 2 coin exchange. Say you wanted to exchange 2 CwapCoins for 5 ShetCoins. Say both of which are closely equivalent to 0.1BTC.

Then an Oracle could facilitate the transaction so long as they have put 0.1BTC as collateral. In other words they could only guarantee transactions in the amount of collateral they have put in.

In the even that the Oracle takes the coins and runs, the collateral is then easily distributed by including a proof that the Oracle has not done the right thing. There could be a separate "Court" chain that can follow those rules without the needs of judges.

Just a thought. I agree though that yes in most cases instead of negative reinforcement, you could provide positive reinforcement and enough incentives for an Oracle to never do bad.

Keep in mind however that an Oracle's machine could be hacked. Even if they mean well others might take advantage of their situation. Just like an eBay powerseller could be shaken and used to scam with fake big ticket items.

In short: I think insurance/collateral has its merit and is not entirely out of the question. Insurance might be easier to implement, than tracking down bad oracles.

I haven't seen your code yet and I may be misunderstanding what you're doing but that implies you've got 39 to 79 public keys or hashes in a single script, which doesn't sound feasible on the current bitcoin network, absent a lot of ECC clevers.

Either way, what makes managing these risks a bit harder than it might sound is that:
1) A lot of your risks are highly correlated, so the redundancy is actually reducing the probability of a fail less than you'd like. (See the earlier point about Fukushima-1, who had five separate methods of powering their cooling systems, did their Probabilistic Risk Assessment and calculated that they'd get one melt-down every 21 million years, but failed to account for the fact that when the 900-year tsunami showed up, it would take out all five at once...)
2) The "moment" is actually the duration of your contract. There are some use-cases where it's almost instant, but for others it could be quite a long time...

Edit to add: You need to be a bit careful how you design this to avoid opening up new holes but if you haven't already, you might want to consider features to switch out oracles that have been proven bad before the contract is up and create a new contract with replacements that are still standing.

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.

Yup, that sounds like something that would be particularly valuable for kolinko's model, because the people running the nodes don't otherwise have any skin in the game, aside from their personal reputations.

BTW, although we obviously like to use our own tools for everything, in some circumstances oracle insurance might actually turn out to be a job for a big, old-school legacy insurance company rather than a blockchain-based setup whose failure modes may end up looking too much like the failure modes of the thing they're insuring...