[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[Riseman]

I guess there'll be a public testnet running for several weeks before the launch.

[sczmiaomiao]

Elastic Project

http://www.elastic-project.com is a non-profit community driven website, created by and for the developers, other community members and those interested in this project, to surge information and helpful advice on everything related to Elastic.

The overall goals of the website are:

• To be the public face of the Elastic Project
• To be a useful resource to current Elastic Project users, testers and developers
• To be a place that those current users can point others to for info and updates

This thread is too long to read, and extracting every information is just too much to handle, so please explore the website to obtain supplemental information.

What are the total number of coins?
And how much will 1 BTC buy? and where can i buy this coin?

[Selsonblue]

I guess there'll be a public testnet running for several weeks before the launch.

As someone with super node ownership aspirations and some software dev. experience. I really hope the nets up and tested for a few days at least, before people start redeeming.
But I trust in the devs so whatever happens, happens.

[Selsonblue]

Elastic Project

http://www.elastic-project.com is a non-profit community driven website, created by and for the developers, other community members and those interested in this project, to surge information and helpful advice on everything related to Elastic.

The overall goals of the website are:

• To be the public face of the Elastic Project
• To be a useful resource to current Elastic Project users, testers and developers
• To be a place that those current users can point others to for info and updates

This thread is too long to read, and extracting every information is just too much to handle, so please explore the website to obtain supplemental information.

What are the total number of coins?
And how much will 1 BTC buy? and where can i buy this coin?

The main network is not live yet for Elastic. There will be updates in the near future (week or so) to give more information on the main net.

You cannot buy XEL (Elastic Coins) on any exchange, at this time.

[boomboom]

Is anyone planning to start a supernode hosting service? I have enough coins but not the skills or hardware, happy to do a revenue sharing deal.

[Bgjjj2016]

Is anyone planning to start a supernode hosting service? I have enough coins but not the skills or hardware, happy to do a revenue sharing deal.

what are the benefits and setbacks ( pros/cons) of being a supernode?

[MiningSev0]

Is anyone planning to start a supernode hosting service? I have enough coins but not the skills or hardware, happy to do a revenue sharing deal.

Call me a bit too negative - but i don't think that someone would get up with this because if the supernode fails your coins are gone and i guess you don't want that to happen - but the 'SN-Administrator' which got the hardware and 'skills' wouln't take risk to compensate you that much - if he said so we would have a big usecase for a smartcontract maybe (yeah - i never had, until now, an real-life-fully-automatisationable-usecase for such a contract without ANY third party confirming it   ) in ETH
Maybe such a process could get implemented in the future:
Admin of the node sends the compensating amount to a locked adress (if you don't accept the amount it would be charged back a week later) - if you accept the contract - the amount would ne locked for a predefined time if the node fails (not reachable for x seconds or something like this) you get this amont - otherwise the admin would get a Full chargeback after the predefined time.

I meant: For now you could use eth - later such a function could get implemented.

[coralreefer]

The more I read comments regarding the SuperNodes (and there are many good ones out there), the more I feel that the initial release of XEL should not include SuperNodes.  Although, I think the community will find out quickly that XEL really needs the SNs (i.e. I doubt any exchanges will even list XEL w/o them because it now means they are processing ElasticPL work in their exchange). 

There are just too many open questions and too much uncertainty being expressed here.  In my opinion it will take a couple of months to fully vet out all these design questions and deploy a fully tested SN solution.

But I have no say in this...I'm just observing what is going on.

[Bgjjj2016]

The more I read comments regarding the SuperNodes (and there are many good ones out there), the more I feel that the initial release of XEL should not include SuperNodes.  Although, I think the community will find out quickly that XEL really needs the SNs (i.e. I doubt any exchanges will even list XEL w/o them because it now means they are processing ElasticPL work in their exchange). 

There are just too many open questions and too much uncertainty being expressed here.  In my opinion it will take a couple of months to fully vet out all these design questions and deploy a fully tested SN solution.

But I have no say in this...I'm just observing what is going on.

Hi Coralreefer, first of all, thank you for your hard work ! I think the uncertainty around SN is mostly because some of us ( like myself) are not tech savvy. We don't know ( in plain language) the pros and cons of having ( being) a SN. Is SN for regular people or tech experts ? Also, the fear of making mistake and losing 250K is also a big concern. How can this be avoided ? I appreciate if you could shed some light on these concerns in plain English 

[ImI]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

[coralreefer]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

Simply because that's the current design that's in git. 

We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work.  But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer.

[cyberhacker]

the update is coming today?

[ImI]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

Simply because that's the current design that's in git.  

We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work.  But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer.

I get that and agree.

Edit: Eventually its a possibility to release in several stages? Like Ethereum does for instance with Metropolis or Homestead.

Stage 1 = "Elastic C64"

Stage 2 (adding SNs) = "Elastic Amiga"

 

[coralreefer]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

Simply because that's the current design that's in git.  

We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work.  But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer.

I get that and agree.

Edit: Eventually its a possibility to release in several stages? Like Ethereum does for instance with Metropolis or Homestead.

Stage 1 = "Elastic C64"

Stage 2 (adding SNs) = "Elastic Amiga"

 

That's kind of the approach I hope we move to.  I know EK is pretty busy now days, but hopefully he will have some time to provide his feedback on how he'd like to proceed.

[trader19]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

Simply because that's the current design that's in git.  

We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work.  But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer.

I get that and agree.

Edit: Eventually its a possibility to release in several stages? Like Ethereum does for instance with Metropolis or Homestead.

Stage 1 = "Elastic C64"

Stage 2 (adding SNs) = "Elastic Amiga"

 

i like your proposal a lot, imo that solves two problems.
1. getting long anticipated mainnet release on
2. taking pressure off the EK and coral away so they can have time to bring quality update stream.

[techwriterjoe]

A lot of comments talk about the"rush" we are in. I'm not worried a bit about more development time. This is how software dev works. We set a deadline, we sort of meet it, and then we realize we need more goals. We set deadlines for those goals, sort of meet them, and realize we have more goals. At some point, the head devs take a step back, realizes what they have is perfectly ship-able and ships it!

Also:
"If you're not embarrassed by the first version of your product, you've launched too late."

Take your time, hurry up. Whatever is being developed, people should still be having fun. So don't rush so much the fun evaporates.
 I'm just hoping it's weeks not months. Feel free to make a timeline. Feel free to not worry about a timeline for another week or so.

[tomkat]

Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?

Simply because that's the current design that's in git.  

We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work.  But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer.

Would it be possible to add "a switch" that could be used to not accept jobs to be processed by a node?
The exchanges could use wallet features only, and we could continue working on developing SNs.

[wpalczynski]

The more I read comments regarding the SuperNodes (and there are many good ones out there), the more I feel that the initial release of XEL should not include SuperNodes.  Although, I think the community will find out quickly that XEL really needs the SNs (i.e. I doubt any exchanges will even list XEL w/o them because it now means they are processing ElasticPL work in their exchange). 

There are just too many open questions and too much uncertainty being expressed here.  In my opinion it will take a couple of months to fully vet out all these design questions and deploy a fully tested SN solution.

But I have no say in this...I'm just observing what is going on.

Is there no functionality in the software to only act like a wallet and not do any processing?

[neolinkhati]

Today...Launch of mainnet?

[coralreefer]

The more I read comments regarding the SuperNodes (and there are many good ones out there), the more I feel that the initial release of XEL should not include SuperNodes.  Although, I think the community will find out quickly that XEL really needs the SNs (i.e. I doubt any exchanges will even list XEL w/o them because it now means they are processing ElasticPL work in their exchange). 

There are just too many open questions and too much uncertainty being expressed here.  In my opinion it will take a couple of months to fully vet out all these design questions and deploy a fully tested SN solution.

But I have no say in this...I'm just observing what is going on.

Hi Coralreefer, first of all, thank you for your hard work ! I think the uncertainty around SN is mostly because some of us ( like myself) are not tech savvy. We don't know ( in plain language) the pros and cons of having ( being) a SN. Is SN for regular people or tech experts ? Also, the fear of making mistake and losing 250K is also a big concern. How can this be avoided ? I appreciate if you could shed some light on these concerns in plain English 

Bgjjj2016, I missed this post earlier. 

 - From a user perspective, the advantage of running a SN is that you will receive a percentage of all mining rewards.
 - From a community perspective, we would need enough SNs running so that all active miners can have their work quickly validated...this will obviously depend on network size.
 - It's really up to the individual if they run one...but honestly, I would think there would only be about 10 to 100 running...it's not meant to replace the miners...it's just people that want to support the network and goal of xel.

I completely agree with the concern around the potential to lose 250K xel...I personally think the network would need some extended testing to prove to all of us that this is implemented correctly.

Again the main reason for the SNs is that the core client (the java code you run for your wallet) is used to secure the network and process transactions.  Unlike other coins, we don't have a fixed POW algorithm...I could easily come up with something where the POW / Bounty validation takes 1 full second.  Now think about the core server having to process all the wallet transactions as well as having to potentially solve 100s or 1000s of these validations dumped on it...it would bring the network to it's knees...this is where the concept of the SN came from (we probably should have chosen a different name as it has nothing to do with securing the network like other coins)...we were just moving all the validation logic out of the core client (i.e. wallet).

If we don't have SNs, we would just have to limit the size / complexity of the work that xel can do (which in turn limits its usefulness to those needing problems solved).

Regarding the suggestion to add a flag to allow the wallet to not process ElasticPL work...I still think its a good short term fix (but my vote doesn't count as I don't work on the core client)...but my guess is the reason this flag didn't exist in the first place is...what if everyone turned that flag off...then there would be no one to process ElasticPL jobs and the xel concept is dead.  Or maybe a more realistic scenario...let's say you want to run a POW miner and you have 10 Peers, but all those Peers have the flag off...even though everyone else in the network may be processing ElasticPL jobs, you would be out of luck as a miner because your peers cannot support you.

Hopefully this answers your questions, but unfortunately I know little to nothing about coding p2p networks so I am of little help here as the open SN questions are mostly network related.