Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Orisi White Paper
Clone this wiki locally
####Orisi, the distributed oracles system for cryptocurrency contracts. Make sure you read mastering distributed oracles afterwards.
Distributed contracts allow a person to initiate a send transaction which will finalize if and when certain conditions are met. While blockchain-only contracts using Bitcoin Script allow for some interesting rules and contracts, in most situations a so-called oracle is needed - an arbiter interacting with the outside world and deciding whether a set of conditions took place or not.
The obvious practical issues with such contracts is the trust required from the oracle:
- The oracle can be hacked.
- The oracle process is opaque - we can never be 100% sure of the oracle’s program or of what it will output.
- The oracle can disappear between the transaction setup and finalisation.
- The oracle may be bribed to deliver faulty results.
There are proposed solutions for the above problems, but we believe that the single-server-oracle approach is inherently flawed. What we propose instead is a creation of a distributed set of oracles run by independent and trustworthy parties.
Instead of one, we have a whole set of oracles. The majority of them need to agree on the outcome for the transaction to be finalized. We believe such a solution should be sufficient to protect any contract:
- It would be very hard and expensive to bribe more than half of the oracles.
- The judgement process is transparent due to the open source nature of the project.
- Server hacking would be extremely difficult due to the variety of oracle hosting providers and server solutions (e.g. some oracles run on Windows, some on Linux; some on AWS, some on home laptops).
- The software will become secure over time with ongoing community involvement.
How the protocol works (simplified example)
- Let’s say that Alice promises to send Bob 2BTC as soon as it starts raining in Death Valley, California. They both agree that the condition will be met once the site http://deathvalley-weather.info/ contains the phrase “it’s raining today”.
- Furthermore, Alice and Bob choose 7 nodes from the default node list at The Oracle List. In theory, they could choose any set of running nodes, but the default list is curated and contains the most reliable/trustworthy nodes. Choosing from the default list also saves time and effort that would otherwise be spent on list negotiation.
- Alice now transfers her money to a temporary multisig address / “safe”. The money will be stored in the safe until 4 of the 7 chosen oracles decide that either the condition is met and the money should go to Bob, or that the money should get sent back to Alice.
- What we don’t want though is to create an address that requires simply 4 of 7 oracle signatures, because that would allow for the majority of the oracles to send the money to an arbitrary address. We would ideally want both the fund receiver's signatures, and 4 of 7 oracle signatures.
- Transaction of 1+(m of n) signatures would be non-standard, but we can hack around this limitation. Alice creates an 8 of 11 multisig “safe”, where 7 of the signatures belong to the oracles, and 4 of the signatures belong to the receiver. With such a setup, the transaction needs both receiver's, and at least 4 out of the 7 oracle's approval to forward the funds to the destination address. In other words, we turn 1+(m of n) into (n+1 of 2n-m+1)
- Alice creates an “unlock” transaction which forwards the funds from the safe, and pays fees to the oracles and to the Orisi project.
- Alice sends the transaction to the oracles via a broadcasted Bitmessage, along with the redemption rules. We use Bitmessage as the protocol of communication with the oracles as an additional way of protecting their IP addresses and providing extra security.
- The oracles check the validity of the transaction and rules. If they are valid, they add the transaction to their schedulers and reply with acknowledgement via a broadcasted Bitmessage.
- Both Bob and Alice make sure that all the oracles acknowledged the validity of the transaction. If so, they then send funds to the safe. The contract is now active.
- After many months, a drop of rain falls in Death Valley and the site deathvalley-weather.info displays a flashing sign: “it’s raining today”.
- The oracles, one by one, notice the message on the website and add their signature to the transaction. The signed transaction is then broadcasted via Bitmessage.
- Once there are enough signatures, Bob grabs the transaction off Bitmessage, and broadcasts it over the Bitcoin network. The funds are released.
Why Bitmessage is used as the communication channel
There are a few reasons to use the Bitmessage protocol instead of direct IP communication:
- We want to protect the anonymity of nodes so it’s harder to attack them.
- The proof of work required to sign Bitmessages prevents spam.
- Bitmessage provides nice and easy broadcasting capabilities - we want the communication to be as transparent as possible so node monitoring is easier.
What if the source website gets DDoSed / becomes unavailable?
All the verdicts will have a clear procedure to be followed when such an event occurs.
For now, only the timelock verdict is implemented - this requires no external communication and doesn't rely on external factors. The second verdict kind, coming very soon, is the BTC price tracker. The BTC price tracker will simply assume the last valid price it managed to obtain.
For generic data sources, there will probably be a rule that the verdict should happen as soon as possible after a given date, but with no guarantee regarding the exact time. In other words - no contract should state “check site X exactly at 8 am”, it should instead say “check site X as soon as possible after 8 am”.
What if source website gets hacked?
Orisi eliminates oracles as the points of failure, but the data feed can still get corrupted. There are a few ways of protection:
- Use a data-feed that would be prohibitively expensive to hack if it were just for the contract manipulation e.g. for Bob it’s probably safe to protect his 1BTC contract with a data-feed from accuweather, as it would cost far more than 1 BTC to hack accuweather.com. unless Alice also signed 1 BTC contracts with a hundred other actors
- Use one of the dedicated oracle data-feeds. e.g. a data-feed that double checks the bitcoin prices against more than one source, has human verification, or heuristics to detect corrupted feeds
- Use oracles supporting the mediation protocol. Some of the future oracles will have an option to mediate - that is, within a set amount of time Bob will have an option to challenge the verdict, and a human operator will deliver an arbitration.
Transaction kinds and the project roadmap
|timelock verdicts||Oracles sign the transaction after a timelock expires. limited practical use, mostly for the sake of early tests of the Orisi network||done|
|btc price verdicts||Verdicts based on a Bitstamp price at a given time - if the price is above X, send money to Alice, otherwise send to Bob. still leaves room for data-feed corruptibility, but should be relatively secure||very high|
|website/boolean||Checks a url for the presence of a regular expression after a given time. if matches - send money to Alice, otherwise send to Bob. In case the website is unavailable, try again after an hour or send to Charlie for further mediation||high|
|website/integer||Like website/boolean, but extracts a number and compares it to another number||after website/boolean|
|other dedicated feeds||Dedicated and secure implementation of various feeds. e.g. a weather feed could check weather from various sources and decide what’s the proper resolution||high|
|arbitration support||Orisi waits for a short while before releasing the funds. if a challenge happens either from Alice or Bob, the funds get forwarded to Charlie||medium|
|human mediation||Instead of sending funds to Charlie when a challenge appears, the node administrator is asked to deliver a ruling||after arbitration support|
|human feeds||Orisi node awaiting administrators to manually verify the feed every day/every hour. This is an expensive process, but quite secure - a human operator could check various signs to make sure that they weren’t hacked in any obvious way||low|
|safety net||Additional safety feature for splitting the money between Alice & Bob, or sending it to a second-level arbiter if the oracles can’t get enough signatures for a long period of time. e.g. because over 50% of nodes went offline in the meantime||low|
|Ethereum support||We’re going Bitcoin first because it can already support real world applications. Ethereum has not launched yet, so it’s lower priority, but we would love to see someone implement Orisi for Ethereum test net transactions||medium|
|contract amendments||Given enough time, some oracles will fall or lose their private keys. This puts a long-term management of a contract at risk. Once contract amendments are implemented, if over 50% of oracles notice that one of them fell, they can transfer the contract funds to another multisig address, with the dead oracle replaced by another one, allowing for safe and long-term contract management.||medium|
|sidechain management||Once we’re able to keep the contracts maintained long-term, we can build oracles for blockchain sidechains management ( original sidechain proposal, a good explanation of sidechains ). That is, instead of a cryptographic protection of locked funds, we’d have a set of oracles guarding them. Not as safe, but far easier to implement and much more versatile.||after amendment support|
We imagine that there will be various sets of oracles handling various kinds of arbitration. Some administrators will want to run a low-fee node handling only simple BTC price & website/boolean verdicts, while some other administrators may want to run nodes that specialize with human arbitration with much higher fees.
Notes and further reading
- SchellingCoins, and TruthCoins offer a different approach to a similar kind of a problem we’re trying to solve. We believe our approach is the most practical one - especially because it can work directly with Bitcoin blockchain with no nonstandard scripts required.
- Another way of choosing a list of oracles would be using a Delegated Proof of Stake. Unfortunately, DPoS implementation might prove to be tricky in the realm of oracles. One could imagine a situation in which an equivalent of 1000 bitcoins is needed to introduce corrupt oracles into the system. If this was just a currency, it would be unwise to spend 1000 BTC to destroy the system. In case of oracles, it may be worth to spend 1000 BTC as soon as above 1000 BTC in transactions rely on the system.
- Ethereum White Paper contains a section called “Further applications” - it is quite a nice overview of possible contract types. Most of them could be implemented by Orisi/Ethereum duo.
- We also considered oracle lists being stored in a distributed fashion - with 51% of oracles deciding who gets added and who gets removed from the default list. Such an approach wouldn't need a central website to store the lists, and wouldn't rely on a single administrator. On the other hand, it would be much harder to build new oracle groups (e.g. a group of oracles supporting human mediation, a group of sidechain management oracles). It would also introduce another risks - oracle owners not spending enough time to consider who to vote in or out of the system, or risks of 51% attack on the system. The single-list-distributed-resource approach already exists in the wild, in the BitTorrent world. While the data gets shared peer to peer, there are centralised torrent lists like Pirate Bay or Demonoid.
- M of N as valid transactions - as of 12th June 2014, M of N transactions have no limitations to the size of N within the protocol per se. BUT bitcoind will complain when trying to generate transactions above 15 required signatures, and anything above 3 signatures will be considered non-standard due to high transaction size. We managed to get those a transaction of 8 of 15 transmitted through the Eligius pool, but it took a moment. With 7% hashing power it has today, it takes around 1-2 hours for the block to be accepted.