wiki

I got this article a day before from a friend and he brought up the question which I have no answer for: > what if all 14 are assassinated? > 14 is not that many, especially when they meet occasionally Then I was just reading the https://github.com/orisi/wiki/wiki/Orisi-White-Paper which has a "contract amendments" section saying: "... 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." which sounds like they don't have plan for 100% death rate either. I guess in case of such an horrible event, we would finally setup a different process which wouldn't require the collocation of several people...

It was a project idea, with some novel concepts introduced in our Whitepaper ( https://github.com/orisi/wiki/wiki/Orisi-White-Paper ). The bitcoin community changed a bit, but the fundamentals haven't and the concept we introduced is still awaiting a proper implementation. Why it got submitted - I don't know who did it, it was neither one of us! But it's nice to see that someone's still interested in what you did. One thing that I really should do is some kind of closure & public after action review...

The project is on hold since a year ago, but here's a link to the whitepaper if anyone's interested: https://github.com/orisi/wiki/wiki/Orisi-White-Paper If anyone has any questions feel free to ask here.

With a small change to bitcoin protocol it should be possible in some cases. But right now the only viable option is to use M of N oracles: https://github.com/orisi/wiki/wiki/Orisi-White-Paper http://gavintech.blogspot.com/2014/06/bit-thereum.html Basically, you choose a panel of up to 15 independent entities to verify that the funds were locked indeed. The panel can be modified by a majority of votes if some of the entities prove to be unreliable - kind of like the Supreme Court works. This obviously introduces a new vulnerability to the system, but is the best solution available right now.

If you're curious about the subject, you might want to watch one of our (Orisi.org) tutorial videos: https://www.youtube.com/watch?v=boPW1FwNu4c . It's a part of a longer tutorial available here: https://github.com/orisi/orisi , and a part of the system described in this whitepaper: https://github.com/orisi/wiki/wiki/Orisi-White-Paper As for your question - it really depends on the way the contract is structured. In theory you could have a 2 of 3 signature address and a timelocked/nLockTimed transaction sending money to an additional arbiter if the time passes without a resolution.

On a related note - all the blockchain contracts are limited by their inability to access real world data (e.g. stock prices, websites). For that you need distributed oracles: https://github.com/orisi/wiki/wiki/Orisi-White-Paper

I'm a founder of Orisi.org, and I just wrote a tutorial explaining how to perform an example bitcoin transaction using M of N oracles: https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction If anyone wants to watch those multisig transactions, you can do so here: https://blockchain.info/address/1PCkVX19uGm2QK1vhcXy9uM4y2jwR4dgbF The details of what M of N oracles are, and how they allow for a creation of bitcoin smart contracts: https://github.com/orisi/wiki/wiki/Orisi-White-Paper http://gavintech.blogspot.com/2014/06/bit-thereum.html

Relevant? Bitcoin itself has very limited functionality for smart contracts, but a set of distributed oracles could change that. We're building such a system here: http://orisi.org/ and there's a whitepaper available here - https://github.com/orisi/wiki/wiki/Orisi-White-Paper A similar system could be used for Ethereum as well, to bring external inputs into the mix.

Well, sidechains will always be useful. Even if zerocash and ethereum were to be included in Bitcoin, we'd still use a playground for testing experimental features. When it comes to updating the Bitcoin protocol, there's a need to be very conservative and very cautious. The core dev team is working on a 2 billion-dollar running train over there. You wouldn't want to push changes too much. And even when sidechain support gets implemented back into Bitcoin, the sidechains will have to conform to a very specific standard. Otherwise bitcoin scripts will not work with them. On the other hand, sidechains based on distributed oracles ( like Orisi - http://github.com/orisi/wiki/wiki/Orisi-White-Paper ), can have any kind of form. If you want to make an alt-currency that sends you a chicken for each bitcoin you burn, and gives you back a bitcoin o

Hah, just this morning we published a whitepaper explaining such a solution in greater detail: http://github.com/orisi/wiki/wiki/Orisi-White-Paper There is also a basic implementation of such a system that we've been preparing for the past week, and a website that will host a list of oracles: http://oracles.li/