[ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 150.

tomkat

hero member

Activity: 1022

Merit: 507

Quote from: ttookk on February 22, 2017, 04:08:24 AM

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

Progressive collateral would be good if we're listed on exchange (so you could buy some), or there're jobs for which supernode owner could get XEL.
It's rather unlikely to start getting XEL immediately after launch

hagie

hero member

Activity: 792

Merit: 501

Quote from: Limx Dev on February 22, 2017, 04:21:25 AM

Quote from: ttookk on February 22, 2017, 04:08:24 AM

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

I think that is possible but we have currently 86 ico members with more than 300K XEL.
https://dl.dropboxusercontent.com/u/21000833/Elastic/Icolist/Ico-list.txt

Uhh looks like I missed the 300K collateral thing. Too bad I really want to run a supernode beside the public node. Is the collateral for the guardnode the same ?

Time to look for partners to get the needed amount of xel :-)

regards

Limx Dev

copper member

Activity: 2324

Merit: 1348

Quote from: ttookk on February 22, 2017, 04:08:24 AM

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

I think that is possible but we have currently 86 ico members with more than 300K XEL.
https://dl.dropboxusercontent.com/u/21000833/Elastic/Icolist/Ico-list.txt

ttookk

hero member

Activity: 994

Merit: 513

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

Limx Dev

copper member

Activity: 2324

Merit: 1348

Quote from: tomkat on February 22, 2017, 03:54:24 AM

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.

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

-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.

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

-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?

-introducing supernodes and guardnodes makes the ecosystem much more complex

Also, do we know anyone interested to run supernode at launch?
If not, then we can expect no supernodes, unless developers will run one.

I think 300K is okay. You can start with 100Mio Xel ~333 Server.

tomkat

hero member

Activity: 1022

Merit: 507

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.

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

-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.

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

-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?

-introducing supernodes and guardnodes makes the ecosystem much more complex

Also, do we know anyone interested to run supernode at launch?
If not, then we can expect no supernodes, unless developers will run one.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Quote from: coralreefer on February 21, 2017, 05:57:08 PM

Quote from: Evil-Knievel on February 21, 2017, 05:50:26 PM

Quote from: coralreefer on February 21, 2017, 05:13:38 PM

Quote from: Evil-Knievel on February 21, 2017, 04:29:55 PM

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs). But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being:

1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there
2) Using SNs would allow us to increase the memory available to ElasticPL jobs

If either or both of these are the case, I would think SNs are required for ElasticPL processing.

Yeah, the main reason was to have more ram and to support a higher WCET (how high, we still have to specify). Otherwise, we would have to limit the available resources to what we expect the weakest nodes in the network to have.

Nice side effect, no matter how crippled the ElasticPL language is, it can never halt the network. This can be also seen as: no code is executed anywhere else than on guard nodes and super nodes - worth to mention to those, who are potentially afraid of this since they want to run Elastic on critical systems such as exchange servers.

coralreefer

sr. member

Activity: 464

Merit: 260

Quote from: Evil-Knievel on February 21, 2017, 05:50:26 PM

Quote from: coralreefer on February 21, 2017, 05:13:38 PM

Quote from: Evil-Knievel on February 21, 2017, 04:29:55 PM

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs). But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being:

1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there
2) Using SNs would allow us to increase the memory available to ElasticPL jobs

If either or both of these are the case, I would think SNs are required for ElasticPL processing.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Quote from: coralreefer on February 21, 2017, 05:13:38 PM

Quote from: Evil-Knievel on February 21, 2017, 04:29:55 PM

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs). But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

coralreefer

sr. member

Activity: 464

Merit: 260

Quote from: Evil-Knievel on February 21, 2017, 04:29:55 PM

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs). But in the least I don't think we should allow any new work to be submitted if there are no SNs.

Evil-Knievel

legendary

Activity: 1260

Merit: 1168

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

techwriterjoe

member

Activity: 95

Merit: 10

I suppose you could think of it as a "public beta release"? There probably isn't a better way to test than to get some actual users.

Bgjjj2016

sr. member

Activity: 448

Merit: 250

Ben2016

Quote from: tomkat on February 21, 2017, 10:48:52 AM

Quote from: bspus on February 21, 2017, 09:35:21 AM

Quote from: tomkat on February 21, 2017, 09:17:51 AM

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

That's how I understand EK's proposal to allow users to launch the mainnet by simply start using the system.
Don't know if it's good or bad, but there will be bugs after that for sure. I think we just need to make sure there're no major flaws, and the system works as expected.
Also, nobody has seen supernodes and guardnodes yet, so we'll need to test it too before going "live".

Your explanation makes sense. Thank you !

tomkat

hero member

Activity: 1022

Merit: 507

Quote from: bspus on February 21, 2017, 09:35:21 AM

Quote from: tomkat on February 21, 2017, 09:17:51 AM

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

That's how I understand EK's proposal to allow users to launch the mainnet by simply start using the system.
Don't know if it's good or bad, but there will be bugs after that for sure. I think we just need to make sure there're no major flaws, and the system works as expected.
Also, nobody has seen supernodes and guardnodes yet, so we'll need to test it too before going "live".

Bgjjj2016

sr. member

Activity: 448

Merit: 250

Ben2016

Quote from: bspus on February 21, 2017, 09:35:21 AM

Quote from: tomkat on February 21, 2017, 09:17:51 AM

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

These are all speculations until we hear from EK.

bspus

legendary

Activity: 2165

Merit: 1002

Quote from: tomkat on February 21, 2017, 09:17:51 AM

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

tomkat

hero member

Activity: 1022

Merit: 507

Quote from: hagie on February 21, 2017, 06:24:01 AM

Quote from: Evil-Knievel on February 20, 2017, 03:08:38 PM

Quote from: by rallier on February 19, 2017, 05:47:04 PM

@EK last week in your roadmap, do you have any updates for us?

Whole package arrives as promised on weekend, including a full documentation and in fully operable state.
The roadmap was reorganized a bit, but (from my side) everything went (and goes) as planned.

So no more testnet before mainnet launch ?

regards

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

CyanFox

sr. member

Activity: 242

Merit: 250

XEL is almost ready, glad to see the news, we investors wait so patiently, we finally will get paid. No doubt that the project is gonna moon.

hagie

hero member

Activity: 792

Merit: 501

Quote from: Evil-Knievel on February 20, 2017, 03:08:38 PM

Quote from: by rallier on February 19, 2017, 05:47:04 PM

@EK last week in your roadmap, do you have any updates for us?

Whole package arrives as promised on weekend, including a full documentation and in fully operable state.
The roadmap was reorganized a bit, but (from my side) everything went (and goes) as planned.

So no more testnet before mainnet launch ?

regards

MiningSev0

full member

Activity: 206

Merit: 106

Old Account was Sev0 (it was hacked)

Quote from: techwriterjoe on February 20, 2017, 05:49:43 PM

4) At this point, XEL should have a BTC/dollar figure amount, since other users need to be able to buy XEL to use the distributed computer.
i. if an outsider wanted buy XEL, then one of the XEL investors would have to sell, since there is a fixed amount?

5) Users also begin the mining process, adding processing power to the distributed computer network

6) At some point after launching main net, the project decides to be listed on exchanges (the same day? days later? weeks later? months?).

7) Once listed on exchanges, the Elastic/XEL wallet is able to interact with exchanges and XEL could be traded for BTC?

Do XEL miners receive XEL as payment? If so, where does that XEL come from? There is already a fixed amount distributed among initial investors.

4&5 -> pls See the picture here

6. Exchanges decides themself if they would like to add us - i think it wouldn't took much time

7. The Exchanges would use whatever currency pair they would use - maybe only dogecoin Wink

- what i mean: The Exchanges aren't our enemys/friends - they just want to earn from the fees traders would pay there and so they would allways search for coins generating much intrest.

--
Written and "painted" on an iPad - sitting in a train and in only a few minutes - i hope i didn't confused you more than you allready have been. English isn't my mother tounge.

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