Hi,
I am a close follower of cryptocurrencies in general, but particularly the Ethereum project. I find the contract-technology developing here very interesting and promising, and might be a game changer for many areas.
However, as I see it, as Ethereum comes to life there will be a need for a trusted bridge between the "real world" and the blockchain. Only with this bridge, you are able to truly create interesting contracts.
I have been looking at existing solutions, like https://www.bitrated.com/ and https://www.realitykeys.com/ (let me know if there are more). While I find them promising, I feel they lack core feature of a successful feed-system, thus I believe that they both can be greatly improved.
What I want to create is something along these lines:
* A webpage where you can use, create or request feeds.
* Feed creators can earn money, and will receive feedback on the quality of their feeds.
* An "ebay-style" rating system for persons providing feeds
* It is up to the feed-creators to design the feed as fully automatic or manual or a combination. Some feeds could have an objection clause, so that the parties of the contract can object to the outcome.
* The feed creators sends data to the Ethereum (or perhaps also Bitcoin) blockchain with the data of the feed. Contracts can use these data to make decision.
* Feeds can be, sports betting, weather, prices on real estate prices, stocks etc.
For instance, let's say you are interested in creating a contract which follows the S&P/Case-Shiller Home Price Indices. In order to do so, you will need a trusted feed that the contract can base its decision on. You then go to this site, and since there is no such feed there, you request it by specifying that you want:
- "a daily updated, end of day, of the S&P/Case-Shiller Home Price Indices, delivered to the contract 12ddccdffefera23rehsfj, and that the feed must last 6 months".
You get a reply from some feed providers that for a 0.79 ETH fee, they will be able to do so. You chose a provider with a high feedback rating.
The feed is designed with an objection period of 24h. This works through the feed creator posting preliminary data which then contract participants can object to. If no objection is made, the feed creator send the same data as in the preliminary announcement. This can remove a lot of feed errors and prevent contracts from making the wrong decision.
The above are only guidelines for a design, but I hope to find others that are interested in developing this further.
I am looking for developers that are familiar with the cryptocurrencies, and have knowledge about Web, Javascript and Python, as these are the core tools I prefer. If you are interested in joining this small project, let me know, and we can discuss the ideas, terms and progress in more details.
best regards
Edward
2 ·
Comments
Should this not be a feature, then yes, maybe a separate website would be a way to go but most of this can be automated as described above. Moreover, having it integrated into Ethereum makes for a better user experience and one that is more decentralized.
My hunch is it may be first best to focus on HTTP responses into contract storage, then move onto the higher order problems of feeds, consensus algorithms, etc. The blessing of the testnet is the worst that can happen is {something really bad} on testnet.
I agree in the sense that, he is kindah talking about adding features that are very general in the specific context of feeds. Reputation systems, for instance. With a DHT and NameReg, each contract/DAO could already have its own pages, which can look at the blockchain to show their reputation.(DAO implementation could possibly go as far as being forced to show correct values) Not sure how fora would work, a fora-per-address would be neat. The request system, i agree that it should exist, essentially a request with a bounty with zero payback, other than the profitability if people come because they wanted it.
That is probably the Web3.0 way to do it. Of course, that doesnt mean the website wont be able to useful work, if the above things end up not implemented yet at launch.
Note that in web3.0 there may be some standards. How do you talk to the reputation system? Will different kinds be able to interoperate? We havent implemented yet. There may be network effects to these standards, so it would be nice to get them right.
edit: ...or at least follow the discussion
I usually only write my own programs, so I have next to nothing of experience with crossborder, open source development. I guess github, google docs and similar will be useful tools, but I am open for best practices from others.
All subject to change of course, but something like this for a short term plan:
- Get hosting. Preferably a provider that accepts bitcoin, and has SSL. Please let me know if you have a provider to recomend.
- Skype (or IRC meetup) for interested parties. Though I am okay with IRC, I prefer to talk to people. It is usually faster in the initial stages. I hope to be able to schedule a skype-chat just to see if we are on the same page regarding the project.
- Agree on legal / license issues.
- Establishing a core team
- Write a todo-list, feature list, and short road-map
- Start implementation (the hard part)
- Start using (the fun part)
Regarding website vs. in-ethereum implementation. Can this be implemented in a good way entirely through JS/blockchain? Anyway, I think that a website is a good starting point, and then you can branch into more and more distributed designs if it materializes.
Further, when I started out on the idea, I planned not to be completely Ethereum-centric in design. Don't read me wrong, I am a BIG fan of this project, but I see that the site could probably be useful for the Bitcoin blockchain as well, though, I might be too greedy with features here. Time will tell, Ethereum should have first priority in my mind.
--
E
Pretty much. The first order of business, before even building anything, may just be to come up with a format so that you can describe a particular feed and know that different information sources will understand the same thing by it. That should make it easier to set up multiple data providers to provide redundant sources of information for the same contract.
I am happy to help the project in anyway I can. My background is in Javascript with some Python as well.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1368412
And then build an incentivation platform depending on trust.
I mostly do front-end and cross-platform mobile apps if you need any help.
If you are interested in the project, the thread is:
http://forum.ethereum.org/discussion/882/congratulations-humanity-you-have-reached-singularity#latest
http://gavintech.blogspot.com/2014/06/bit-thereum.html
inDΞΞD
It might also be interesting to have some kind of registry with all feeds that are live on ethereum