Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 240. (Read 450524 times)

I haven't checked in for a while.  Am I able to claim my coins yet?  If not, is there an ETA for that?  Thanks.

http://golemproject.net/

seems they plan to raise more than 5M USD dollars.

 When and how donators should apply for their stake? Just to be sure. I hope distribution phase will last long enough.

looks great, imo you are missing one more block on each side (left and right) and in the middle round then it would be perfect. try it

Not yet. ETA was one to two months a while back, but based on success/failure, this time may change drastically. The easiest is to assume that it is always a month from now. Then go check again. Or help getting there faster by doing what we are planning to do, which is renting your brainpower out to the elastic network:


(Sorry, picture was quick & dirty)

u are working on documents, testnet success? Are we going mainnet?

Alright, I guess the golem part of the comparison page answered my question about a possible reputation system:


Fair enough.

Great, here we go then 

Elastic Compared to Other Competitors

Ethereum
Gridcoin
Zennet
Voltcoin
Golem
TAU-Chain

http://elastic-project.com/comparison_with_other_solutions


Overview of GIT repositories

http://elastic-project.com/open_source


Explanation for the Elastic IDE

http://elastic-project.com/elasticpl_editor

Done.

Good work!

@Lannister: Can you"patch away" the ugly doku.php from the urls?

Elastic Compared to Other Competitors

Ethereum
Gridcoin
Zennet
Voltcoin
Golem
TAU-Chain

http://elastic-project.com/doku.php/comparison_with_other_solutions


Overview of GIT repositories

http://elastic-project.com/doku.php/open_source


Explanation for the Elastic IDE

http://elastic-project.com/doku.php/elasticpl_editor

EK, your work is very impressive!

Started writing about the key differences to other projects:

http://elastic-project.com/doku.php/comparison_with_other_solutions

Gridcoin and Golem is already there, I will write about Zennet now done.
Did we miss any "approaches"?

EDIT: After re-reading I must admit ... my English sucks  

I think we got one now!

http://www.elastic-project.com/

Now ... we have to fill it with content 

I think we need a website.

around 709 btc

EK,

I'm trying to get my miner / parser I wrote in C up and running, but every time I submit work, I get the error "work_id not specified".  I'm submitting the work using HTTP Post with data of "deadline=3&feeNQT=0&work_id=" + workId + "&inputs=" + strRet2 + "&is_pow=true&secretPhrase=" + secretPhrase"

Do I need to send this data in a JSON format instead?  or do you have an idea why it does not recognize work_id in my data?

The more I think about it, the more I like the idea of a non-mandatory whitelist and reputation system.

The scenario could look like this:

- Under normal circumstances, job authors don't use the reputation system, because they would obviously want to have as many miners working on their job as possible.

- If the system is under attack, job authors can choose to activate the reputation system. This system consists of two parts:

- They can either decide to only let certain miners work on their job. They can create a list of miners, or use the list of another trusted entity.

- They can also set a certain "minimum of approval" threshold. This means, that only miners with the set minimum of approval or more are allowed to work on the job.

- To earn approval, the XEL network can vote for miners. To get people to vote for you, you can share earnings with them (since they hold XEL and are interested in XELs financial well-being, they are interested to vote in legit miners and withdraw approval if a miners shows malicious activity). This system would work similar to Lisks DPoS system, but without a fixed number of Delegates/miners obviously. Miners with zero reputation can mine on the network, but run the risk of getting blacklisted. A miner could still vote for themselves, but ideally, the needed amount would be very high.

I have to admit, that I smell abusive potential, but I can't point my finger at it. The worst I see at the moment is a scenario in which most job authors use the list to whitelist only certain miners, keeping the majority of miners outside of it, but I don't see that as likely…

EDIT: This is a bit out there, but you could also use the whitelist system to chop jobs, so that the risk of a single miner mining the majority of your blocks is reduced. Let's say, you have sensitive data, that you don't want to have in one hand. You could divide them up into different jobs and whitelist different miners for each of those jobs. Obviously, the nodes would be weak links in this scenario…

It was more than 700 - listed somewhere here https://www.ico-list.com/