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

[by rallier]

ICO Users have 300 K XEL or not , doesnt matter, if somebody can want to cheat network with his things, it is possible, somebody bcan buy 300 K XEL on any exchange.

[bifabu.com]

Where can I download the wallet?

[tomkat]

Where can I download the wallet?

See here
http://www.elastic-project.com/installing_and_running_elastic

But wait for new release (this weekend)

[coralreefer]

I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.

I think I disagree with most of what you wrote...

Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user

That is the reason for the 300K...we don't want it easy / cheap for people to create malicious supernodes.

-new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.

If there is only one supernode, then xel has failed it purpose anyway.  What's the point of xel if no one is interested in supporting the network.

-no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network

Huh?  What about POW rewards and Bounties?  Are those not incentive enough to run a regular node?  What other incentives would they need?

-is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?

Yes this scenario is handled in the design.  I'll let EK speak to how it would work.

-introducing supernodes and guardnodes makes the ecosystem much more complex

Ok, this may be the only thing I agree with that you wrote.  Yes it makes things more complex.  But this complexity provides a couple things.

1) Without it, xel can only work on small jobs with limited memory.  With SN, we can increase the size / complexity of the use cases considerably.
2) Read what EK wrote above...without SNs it would mean that for Exchanges, etc to run a wallet, they would be required to verify all the ElasticPL jobs / solutions / pow submissions flowing through the network.  I don't really think you'll find many, if any exchanges that would agree to this.

[tomkat]

I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.

I think I disagree with most of what you wrote...

Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user

That is the reason for the 300K...we don't want it easy / cheap for people to create malicious supernodes.

-new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.

If there is only one supernode, then xel has failed it purpose anyway.  What's the point of xel if no one is interested in supporting the network.

-no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network

Huh?  What about POW rewards and Bounties?  Are those not incentive enough to run a regular node?  What other incentives would they need?

-is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?

Yes this scenario is handled in the design.  I'll let EK speak to how it would work.

-introducing supernodes and guardnodes makes the ecosystem much more complex

Ok, this may be the only thing I agree with that you wrote.  Yes it makes things more complex.  But this complexity provides a couple things.

1) Without it, xel can only work on small jobs with limited memory.  With SN, we can increase the size / complexity of the use cases considerably.
2) Read what EK wrote above...without SNs it would mean that for Exchanges, etc to run a wallet, they would be required to verify all the ElasticPL jobs / solutions / pow submissions flowing through the network.  I don't really think you'll find many, if any exchanges that would agree to this.

Thank you coralreefer. I do hope you're right, and the design is "strong" enough to withstand the test of time :-)
I just wonder why not make it as easy as running regular nodes, and allow node operators choosing whether they want to accept jobs or not?
Or maybe let the network decide if a node has enough resources to allow it to perform jobs processing. Would it be possible to detect configuration and auto-decide?

What I really don't like is complexity since it always leads to problems... I know it's actually little late for this discussion, but the supernodes idea hasn't been discussed on this forum, so no one knows what to expect. [Edit: or maybe I missed such discussion?]

[trader19]

i want to run supernode  missing XEL!!! Can't wait for exchanger.

[MiningSev0]

I also think 300k is a lot, i'm out ^^
But i will build a miner to contribute.
Also i would advise that we should have a simple to use windows client (starting with a directly easy to download, precompiled exe - and open the browser).

[aaronjobs]

i want to run supernode  missing XEL!!! Can't wait for exchanger.

it will be soon, hope XEL can be list by Poloniex

[ImI]

We cannot keep 300k XEL on a VPS somewhere on the net, so we will have to install a system like Dash masternodes, where the activation of the masternode is done via Coins that are held offline.

Otherwise its way to much risk.

[Cryptorials]

How much would one need to have donated to have the 300k XEL for a masternode?

[Selsonblue]

I had a few thoughts come up around the SN discussion:

Pro's
- SN admins will have to be community participants and tech savvy(or at least willing to work with devs)

Cons
- Less SN admins ultimately ends up leading to less SN test scenarios being run - meaning potential zero-days and bugs that wont be discovered by the people who should be discovering them and bringing to community
- Without a SN at network launch to provide feedback on computational rewards - less people would have financial reason to invest in a SN. - I guess people could speculate from regular node rewards.

Other
- We cannot equate relative financial barriers with network security - malicious wrong-doers have access to funds if the risk / reward is justified.

Random Thought: Is there anyway a SN could operate with funds from more than a single participants?  I acknowledge the danger of opening up a communication channel, outside of typical secure channels on nodes, but i guess im trying to get at a sort of read only access between 2 nodes(150k XEL each for example) that would allow them to function as a SN.  For lack of a better term - "known/trusted community/group managed SN".  - An offline approach would also work and increase security of the  XEL holdings.


Another important question:
Are there any XEL community members that can say 100% they are going to set up a SN on network launch?

[Selsonblue]

How much would one need to have donated to have the 300k XEL for a masternode?

Approx 1.5 btc at initial ICO last Feb. would put you at around 300k XEL if my math is correct.

[ImI]

Another important question:
Are there any XEL community members that can say 100% they are going to set up a SN on network launch?

Given its secure i am going to setup some SNs.

[Selsonblue]

Another important question:
Are there any XEL community members that can say 100% they are going to set up a SN on network launch?

Given its secure i am going to setup some SNs.

Well if so, that alleviates some of the concerns I have seen so far about high entry costs into SN ownership.  Kudos ImI ! 

[13Darko]

But by limiting the number of SN we limit the overall supercomputer calculating power, isn't it? If it's gonna be 300k XEL then we'll have the maximum number of 333 supercomputer clusters, 30k XELs means 3330 SN (in the best case scenario, of course).
I agree with ttookk that maybe we could make this number a variable? But only not an increasing, but a decreasing one: from 300k to, let's say, 3k over time due to XEL's price increase and increasing resources consumption.

[Selsonblue]

But by limiting the number of SN we limit the overall supercomputer calculating power, isn't it? If it's gonna be 300k XEL then we'll have the maximum number of 333 supercomputer clusters, 30k XELs means 3330 SN (in the best case scenario, of course).
I agree with ttook that maybe we could make this number a variable? But only not an increasing, but a decreasing one: from 300k to, let's say, 3k over time due to XEL's price increase and increasing resources consumption.

From my understanding the SN's are only validating the computational jobs done by the individual network nodes. I dont see the number of SN's as a factor in overall network computational potential, but I do recognize that having a low # of SN's could create a bottleneck... But either way, the data supporting my claims here doesnt exist yet.

A variable amount for operating SN's might help out. But it seems most are concerned with the Fiat cost of ownership at this point - We cant peg XEL to fiat and expect it to be a accurate 6 months down the road. In addition to that fact, a Fiat / Xel calculation that determines the amount of XEL required for a supernode has absolutely no technical implications on the network.

TLDR: XEL Supernodes =/= Masternodes (DASH, PIVX, ect.) - Network computational power is not supplied by Supernodes alone. You can mine / compute with the other nodes.

[tomkat]

But by limiting the number of SN we limit the overall supercomputer calculating power, isn't it? If it's gonna be 300k XEL then we'll have the maximum number of 333 supercomputer clusters, 30k XELs means 3330 SN (in the best case scenario, of course).
I agree with ttook that maybe we could make this number a variable? But only not an increasing, but a decreasing one: from 300k to, let's say, 3k over time due to XEL's price increase and increasing resources consumption.

From my understanding the SN's are only validating the computational jobs done by the individual network nodes. I dont see the number of SN's as a factor in overall network computational potential, but I do recognize that having a low # of SN's could create a bottleneck... But either way, the data supporting my claims here doesnt exist yet.

A variable amount for operating SN's might help out. But it seems most are concerned with the Fiat cost of ownership at this point - We cant peg XEL to fiat and expect it to be a accurate 6 months down the road. In addition to that fact, a Fiat / Xel calculation that determines the amount of XEL required for a supernode has absolutely no technical implications on the network.

TLDR: XEL Supernodes =/= Masternodes (DASH, PIVX, ect.) - Network computational power is not supplied by Supernodes alone. You can mine / compute with the other nodes.

SNs not only validate the jobs, but also help to keep it all running becasue of limitations of the regular nodes.
But it's pretty obvious the SNs will have their own limits, so not sure if it will resolve the available-resources-related issues, unless we
are sure what config will be capable of handling ALL possible jobs, ie. how many SNs at what specs

[Sicarious]

Hey all, I've been quiet in this thread thus far (I haven't a very technical skilset), but donated at the start of the project and have been thrilled watching all the progress and updates to the project over the past several months.  There was some talk earlier in the thread about getting added to trading exchanges, which I think is an important aspect of building a strong community, as it facilitates new interested parties getting involved in the project.

While I would love for XEL to get on Poloniex.com (widely viewed as the most prominent altcoin exchange), they are pretty random with they aren't very clear on what they look for in their coin additions, so I wouldn't count on it, at least not at launch. But it cannot hurt for us to submit coin addition requests: https://temp.poloniex.com/coinRequest

I think our best bet would be to get added on Bittrex.com. Unfortunately they are pretty stringent with requesting information from the developers of a coin before adding it, namely due to the fact that they want a point of contact if they have any issues with the chain, et cetera. Here is more information on the Bittrex.com addition requirements: https://bittrex.zendesk.com/hc/en-us/articles/202583854-Submitting-a-Coin-to-Bittrex.

https://novaexchange.com, and https://www.cryptopia.co.nz are two other exchanges that might expose us to a wider userbase, though they are not as established as the two listed above.


Cheers to the devs doing all the great work on the project!

[13Darko]

But by limiting the number of SN we limit the overall supercomputer calculating power, isn't it? If it's gonna be 300k XEL then we'll have the maximum number of 333 supercomputer clusters, 30k XELs means 3330 SN (in the best case scenario, of course).
I agree with ttook that maybe we could make this number a variable? But only not an increasing, but a decreasing one: from 300k to, let's say, 3k over time due to XEL's price increase and increasing resources consumption.

From my understanding the SN's are only validating the computational jobs done by the individual network nodes. I dont see the number of SN's as a factor in overall network computational potential, but I do recognize that having a low # of SN's could create a bottleneck... But either way, the data supporting my claims here doesnt exist yet.

A variable amount for operating SN's might help out. But it seems most are concerned with the Fiat cost of ownership at this point - We cant peg XEL to fiat and expect it to be a accurate 6 months down the road. In addition to that fact, a Fiat / Xel calculation that determines the amount of XEL required for a supernode has absolutely no technical implications on the network.

TLDR: XEL Supernodes =/= Masternodes (DASH, PIVX, ect.) - Network computational power is not supplied by Supernodes alone. You can mine / compute with the other nodes.

Thanks. Probably I just misunderstood the concept behind SN. If individual nodes can also mine, that will bring lots of computational power I believe, and maybe we'll be able even to bypass some TOP500 Supercomputers of the World?

Pegging Xel to Fiat is a bad idea, true, but I think we can easily change SN number manually by updating network software (do hardforks if needed).

Edit: Nah, bad idea. Rich SN possibly won't like competition and just won't update...

[cryptoboy.architect]

Why not make it so the network requires X number of supernodes to always be running. And have the collateral be auction based.

i.e. say X is 100 - i.e. we want 100 super nodes to run.

It will self adapt - if someone wants to run 10 super nodes at 300K collateral each so be it.

But if there are 90 who only want to put up 100K, they will be able to participate as well.

The moment someone puts bigger collateral - they take someone else's place in the super node ladder.

Thoughts?