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

[bitcoinpaul]

Just make a poll

Litewallet yes
Litewallet no

to end this discussion.

[1714799761]

1714799761

[yosir]

I would hate to see this project get hijacked by individual that appeared month or so ago and already making statements and promises to other as "community".

Friends, have a patience, please.

This can be amazing project if we won't ruin it with greed. Till now the progress was great and at some point there will be change, but please, use your common sense, don't let "satoshi chasers" ruin this project for all of us and make it one more very promising at beginning but failed at the end project.

   

[ImI]

Folks relax,

we will have a voting. The voting (as it stands right now) will have two options: Lite Wallet Yes, Lite Wallet No. Or (if you prefer another wording) Lite Wallet and Full Client.

BOTH options won't be a catastrophic outcome for the overall project at all. A Lite Wallet has it's advantages and so has waiting for a Full Client. But it's not like we "cripple" the project just cause we choose one of those options. EK already stated we could add new features as a softfork in case we choose the way of a Lite Wallet and it costs him maybe a week of work.

It may be suboptimal in terms of marketprice and yes (as i said before) it would be nice to enter the markets with a "Bam!" but it's not like it's a difference of day and night. Would just be a nice to have, that's all.

And regarding the foundation: That's another question and should not be connected with the Lite Wallet voting.

[yosir]

Folks relax,

we will have a voting. The voting (as it stands right now) will have two options: Lite Wallet Yes, Lite Wallet No. Or (if you prefer another wording) Lite Wallet and Full Client.

BOTH options won't be a catastrophic outcome for the overall project at all. A Lite Wallet has it's advantages and so has waiting for a Full Client. But it's not like we "cripple" the project just cause we choose one of those options. EK already stated we could add new features as a softfork in case we choose the way of a Lite Wallet and it costs him maybe a week of work.

It may be suboptimal in terms of marketprice and yes (as i said before) it would be nice to enter the markets with a "Bam!" but it's not like it's a difference of day and night. Would just be a nice to have, that's all.

And regarding the foundation: That's another question and should not be connected with the Lite Wallet voting.

I am not talking about different opinions, which are all relevant and have pros and cons. I am talking about certain individual who push himself into power position so bluntly that I begin to wonder about his motives.
And I do believe that the one's who did all the "heavy lifting" and the actual work/QA ( + maybe early donors like me) , are the one's who should choose the direction in which this project will go or at least have a veto about it's progress. People like you, that were active long ago before "let's go to exchange/ICO/etc. " 's came.

[meyer]

I'm lurking in this thread since the beginning and I always was impressed by the great spirit in this community. Since some time this spirit is in danger.
Everybody who interested in this project must understand that our great developers just do this work because they want to, because they like the project and the nice spirit here. If you destroy this you could destroy everything... so especially the "greedy ones" should stay calm. If you don't do it because you love this groundbreaking crypto project... do it because it is also makes sense in an economical point of view.

Elastic is on the way to make history... there is no rush. I understand that there is NOW a great bubble and many would like to sell NOW for huge profit. But if you let the developers make there great job and give them the time they need you will get even richer  ;-)
quality wins on the long run !

My thanks to our great devs and the community. I'm glad I bought a little bit ... I wished it would have been more :-)

go on and let elastic come true!

 Thx
meyer

[Bgjjj2016]

Just be very aware of couple people that are using this uncertainty we have right now to make a 200 BTC savior and bring us the Twitter account ( which is free), website and other promises. I love to see Elastic to come with a bam ( I stole this from IMI), but even if not now, we know the " Bam" will come , meantime the keepers don't have to sell ( we actually can add to our positions). Then our Elastic Foundation will come alive using the XEL contribution and we wouldn't need to come up with " at least 200 BTC " from desperation.

[coralreefer]

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

[ronald0cz]

Hi, guys! I like Elastic idea and concept but I can't understand one thing. Can I buy it now or there is no possibility to do it at this time?

[Evil-Knievel]

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

Totally get your point.
The key advantage we have is, that the SN part is entirely disconnected from the core client. This would allow us to start with a "PoC" SN node (which is slower due to task switching) and improve it gradually. This would not require any changes to the core client. To make it even easier, we could think about defining a Bounty-only version as the MVP (to mitigate the fast task switching thing) and move to PoW later on. What do you think?

Regarding the task switching, I already got an idea. Switching libraries sucks, but what if we compile one big library with different functions (run_28727427, run_27627424, run_129929292). This library could be generated every time new work is detected and would only be needed to be loaded once. I could assist with it (or do most of it)

[vivabux]

Guys what is the progress and movement to mainnet in any there?

[unvoid]

Vote for mainet (lite) will start right after logo voting will end.

[lda1000]

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

Totally get your point.
The key advantage we have is, that the SN part is entirely disconnected from the core client. This would allow us to start with a "PoC" SN node (which is slower due to task switching) and improve it gradually. This would not require any changes to the core client. To make it even easier, we could think about defining a Bounty-only version as the MVP (to mitigate the fast task switching thing) and move to PoW later on. What do you think?

Regarding the task switching, I already got an idea. Switching libraries sucks, but what if we compile one big library with different functions (run_28727427, run_27627424, run_129929292). This library could be generated every time new work is detected and would only be needed to be loaded once. I could assist with it (or do most of it)

Would it be SN that has to recompile the library every time a new work is added?
If so, do you guys have any concerns about an adversary submitting cheap work repeatedly to make SN go slower due to CPU being used for compiling?
Also, what if an adversary submits the jobs very quickly and the SN can't keep up with producing the needed library. Would it create a queue that would build up and make the SN unable to validate jobs?

 

[coralreefer]

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

Totally get your point.
The key advantage we have is, that the SN part is entirely disconnected from the core client. This would allow us to start with a "PoC" SN node (which is slower due to task switching) and improve it gradually. This would not require any changes to the core client. To make it even easier, we could think about defining a Bounty-only version as the MVP (to mitigate the fast task switching thing) and move to PoW later on. What do you think?

Regarding the task switching, I already got an idea. Switching libraries sucks, but what if we compile one big library with different functions (run_28727427, run_27627424, run_129929292). This library could be generated every time new work is detected and would only be needed to be loaded once. I could assist with it (or do most of it)

Would it be SN that has to recompile the library every time a new work is added?
If so, do you guys have any concerns about an adversary submitting cheap work repeatedly to make SN go slower due to CPU being used for compiling?
Also, what if an adversary submits the jobs very quickly and the SN can't keep up with producing the needed library. Would it create a queue that would build up and make the SN unable to validate jobs?

lda1000, yes those are the type of concerns we are working through.  They are complex issues which are requiring parts of the workflow to be redesigned.

[wpalczynski]

Perhaps a bounty program such as Monero has could be used to pay for the much needed development work, its been quite successful for Monero.  Community votes for certain bounty proposals put forth by coders with their funds directly.  Once the required amount of funds is collected for that particular piece of the application the developer starts working and gets compensated based on agreed upon milestones.

The only issue with paid coders is that typically they write poor quality code, just enough to satisfy the technical requirements of the proposal in order to get compensated.  I know that some effort is involved on the part of the core team to screen potential coders.

This would be more feasible if the lite wallet mechanism existed allowing people to contribute the XEL tokens themselves to the proposals which could then be sold on exchanges to pay developers if they wanted to get paid in BTC.

[Bgjjj2016]

Perhaps a bounty program such as Monero has could be used to pay for the much needed development work, its been quite successful for Monero.  Community votes for certain bounty proposals put forth by coders with their funds directly.  Once the required amount of funds is collected for that particular piece of the application the developer starts working and gets compensated based on agreed upon milestones.

The only issue with paid coders is that typically they write poor quality code, just enough to satisfy the technical requirements of the proposal in order to get compensated.  I know that some effort is involved on the part of the core team to screen potential coders.

This would be more feasible if the lite wallet mechanism existed allowing people to contribute the XEL tokens themselves to the proposals which could then be sold on exchanges to pay developers if they wanted to get paid in BTC.

I agree with the Lite wallet mechanism. If the devs are invested in XEL, the results are much better.

[Tradingriver]

Although the conversation has again shifted back to a vote about a lite wallet, I'm still not sure what I perceive as the main issue is being addressed....how do we get more devs to help with the coding? 

I just don't want people to go vote for a lite wallet, and we still end up with the same issue.  Having BTC/XEL in a fund won't speed up my progress...I only work on this in my free time when I have nothing else going on...funding won't change that.

So whatever you vote for, the question still remains...how do you get a C programmer (experienced w/ high volume networking...which I'm not) to work on the ElasticPL engine.  Of course they can code in a different language, but that would require porting over everything I've done.

Totally get your point.
The key advantage we have is, that the SN part is entirely disconnected from the core client. This would allow us to start with a "PoC" SN node (which is slower due to task switching) and improve it gradually. This would not require any changes to the core client. To make it even easier, we could think about defining a Bounty-only version as the MVP (to mitigate the fast task switching thing) and move to PoW later on. What do you think?

Regarding the task switching, I already got an idea. Switching libraries sucks, but what if we compile one big library with different functions (run_28727427, run_27627424, run_129929292). This library could be generated every time new work is detected and would only be needed to be loaded once. I could assist with it (or do most of it)

Hey you both!

It seems to me, you both are the most important people for the project. I am for launching "something", the point is you both have to support this solution. I think we need a solution
who will support your efforts the best. We have no funds to support your efforts, but I would be willing to send XEL to you both. I like how you held to this project and kept it alive.

I would suggest you both speak what you want and this is the route we go.

In my opinion, I would prefer to launch an MVP in 1-2 month if possible, because I think it will be good for the whole project if XEL can be exchanged. We can compensate interested people and can get more help for you both on board. My focus is to help you in any way possible. If you do not feel that you need help I am fine with the status right now, but you could take the opportunity to the impatient people and form a structure to help your task.

I am supporting every road you both want to go, but pls provide clear statements what you want like

1. Lite wallet - no
2. MVP - yes
3. starting near perfection - yes

cheers

[MsCollec]

Is there any procedure for claiming the token from the ICO?

[Bgjjj2016]

There's no guarantee for MVP to be ready in 1-2 months. As per Coralreefer, just one of the components of MVP might be ready by December ( he even said pick the year ! , December 2018 ?). Despite titles like " Greedy", " Inpatient ",..... I still think the simple Lite wallet is a good start and after that, also speculation will make this project grow technically and financially. We can donate XEL to the devs, advertisement, etc. and the devs will be invested in the project so their work will benefit them as well, instead of a contract worker getting paid by a limited Bitcoin and after the work is done, they will be gone.
Please don't think through your emotions, think logically what's best for this project in the long run.

[tomkat]

There's no guarantee for MVP to be ready in 1-2 months. As per Coralreefer, just one of the components of MVP might be ready by December ( he even said pick the year ! , December 2018 ?). Despite titles like " Greedy", " Inpatient ",..... I still think the simple Lite wallet is a good start and after that, also speculation will make this project grow technically and financially. We can donate XEL to the devs, advertisement, etc. and the devs will be invested in the project so their work will benefit them as well, instead of a contract worker getting paid by a limited Bitcoin and after the work is done, they will be gone.
Please don't think through your emotions, think logically what's best for this project in the long run.

Yep, looks like we have agreement for lite wallet YES/NO voting, so let's wait for logo voting to end first.

Then unvoid will start lite wallet poll.

Again, tradable token will allow for funding current developers, and attract new ones to help coralreefer and EK.

Perhaps, thanks to this, we'll have MVP ealier than December (this year).

[yosir]

Is there any procedure for claiming the token from the ICO?

Hi MsCollec,

There was no ICO, but only voluntary donations.
You can't claim your XEL till we have mainnet, and this will happen later. When exactly - nobody knows.