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

I'm not sure if there is an official twitter account , i created this some time ago https://twitter.com/elastic_coin . If someone can use it better i'd be happy to provide the access details .

If there was one, it disappeared with Lannister.

Well, access to it.

Is there an official XEL twitter account for updating the twatters?   Asking for tweet tracking in slack to allow for easy RT'ing

It all depends on the jobs submitting by the authors.  This isn't like mining coins...no one knows what logic they want to solve for.  On the todo list is to create logic to determine on a per job basis whether CPU or GPU is better....but this won't be available until someone codes this logic.

If I'm running a system with a powerful GPU is this appropriate for the Elastic network? Or is it purely CPU?

In terms of CPU/GPU, what kind of systems would be suitable?

Repository for elastic-core is here
https://github.com/OrdinaryDude/elastic-core

You can compile and test the basic wallet features, but for testing the network I think we first need SNs and GNs - still waiting...

[Edit: see here for more info http://www.elastic-project.com/installing_and_running_elastic]

Should we expect the release version in this repository today?

https://github.com/elastic-project/core-client

Or we can already compile the code from that another one repository?

Well in true decentralized fashion, implementation of a GN / SN voting mechanism might be appropriate to garner.... dare i say it.... consensus on trusted nodes  

I dont really see how you could start the net without "training wheels" or some hard coded nodes just to get going if there is a  -- If no SN then no work -- clause.  Thats assuming to become a "trusted GN" the node has to have some jobs / work completed correctly

Great updates. I have been chatting with some folks in the slack about specific use cases and marketing them, cant wait to get into the details with you guys soon.

Fun fact: Judgement day was the first R rated movie I saw as a child, ai liquid metal, nuclear holocaust, cyborgs, time travel.... thanks mom. 

Prost!

Allright, makes much more sense to wait for green light then.

we wait, no rush here no supernodes no testing. i would like to run supernode on testnet so i can get familiar with the task   ty EK

@EK

Great work!

But i have to say i am bit worried about the SN and GN stuff, it adds lots of complexity and with complexity you get attack vectors. But lets see, now we have that toy so lets play around with it!

Another thing that gives me question marks is the hard coding of the GNs as it basically makes our solution quite centralized. If we choose the GNs by our trust in xyz then we kinda outplay our efforts to make a decent decentralized computer. So the question is: Could there eventually be a better way of choosing the GNs? Eventually GN that need a small amount of XEL? I am always lookin with one eye at Dash and how they solved this issue with their Masternodes.

I guess we need to get the supernodes ready first. I mean we can all upgrade our nodes to the latest version, but except for the standard functions (sending XEL, redeeming, blah), serious testing will not be possible.

Coralreefer and me, we are right now figuring out what needs to be done ... the specs are the most important part now. Meaning (maximum worst case execution time, maximum runtime in seconds, etc.)

If you like, I can update the amazon EC nodes tomorrow so you can start playing with the current version. But you will hit a point, where the supernodes will become necessary to go to the next testing level.

Also, I will try to write down everything tomorrow, so the PR guys have some more information. If the days only had more than 24 hours. 

nice summarized EK, thank you 

i will try to fire up some nodes. maybe tonight, maybe tomorrow.

it would be great if all would update to newest version so we can do some proper testing? @unvoid @ImI.. i did it but no peer connection still.. any active peer i can use for my config? thanks EK for amazing work so far. time to activate skynet 

Disclaimer: I am a retarded homosapien, so I - by design - might get things wrong. Please do not take this information for granted, it just represents the world, that is spanned by my limited horizon. The reality might be totally different.

Golem is, in my humble opinion, a very fragile construction. It uses an external P2P overlay, it uses the ETH network, it uses Docker containers running python code inside virtual machines ... and they are currently limited to certain types of use cases such as Blender rendering. The plan is to allow arbitrary code ... I am yet to understand how exactly this will work. Fact is (again, in my limited world) that if one of these things has a bug, the whole thing goes to the shitter.

Elastic has a very constrained set of possible use cases, but it is autonomous. It does not need any external shit: we have our own programming language, our own interpreter, we do not rely on any external technology (except the java libraries that are needed to run the core client). Also, our own programming language does not allow shenanigans to do any harm ... it simply does not allow the programming of malicious functionality, not even an endless loop (which would be possible in golem, if my brain does not malfunction now). Unlike golem ... they use a fully featured python behind the scenes. This of course makes it very hard to assess all side effects and possible bugs.

Anyhow, maybe the Golem guys rock the shit, and prove me wrong. I bet they will  

---

http://elastic-project.com/comparison_with_other_solutions#golem

Anyone know how this compares to Golem?