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

[Selerius]

Any volunteer for keeping the PR donations?

IMO, we have to work with proffesionals.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

Based on prior posts of his, I think he would be disappointed that not everyone has noticed he does not want to manage funds.

I agree he would be the perfect candidate for trustworthiness if he was willing, but he has emphasized not wanting to become personally responsible for handling funds.  And that, of course, is his right to choose.  If others step up, that aids the semi-decentralized aspect of the project in a way.  For others, there may be options like a 2-of-3 multisignature wallet with 3 holders, in case one person is away at a given time.

[1715697880]

1715697880

[1715697880]

1715697880

[1715697880]

1715697880

[clivemy]

Any volunteer for keeping the PR donations?

IMO, we have to work with proffesionals.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

Based on prior posts of his, I think he would be disappointed that not everyone has noticed he does not want to manage funds.

I agree he would be the perfect candidate for trustworthiness if he was willing, but he has emphasized not wanting to become personally responsible for handling funds.  And that, of course, is his right to choose.  If others step up, that aids the semi-decentralized aspect of the project in a way.  For others, there may be options like a 2-of-3 multisignature wallet with 3 holders, in case one person is away at a given time.

I don't think we've got to worry about a fund for pre-launch PR, since there's a lot of very willing people to help out with that.

One thing I don't understand though, is that no one seems to be able to tell me exactly what it is that Elastic can do.

Nor can I find any reference to anyone actually testing the core units to see that they can actually solve problems and what those types of problems are.

[bobmarley650]

IMO, We need to know the date that Elastic will be completely ready then we can organise the PR process.

[Bgjjj2016]

IMO, We need to know the date that Elastic will be completely ready then we can organise the PR process.

Updates please !

[cryptodv]

Any volunteer for keeping the PR donations?

IMO, we have to work with proffesionals.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

I don't think EK would want to do that. He stated that his love is coding, he must be burnt out already. Maybe an escrow manager might be more ideal.

[cyberhacker]

Any volunteer for keeping the PR donations?

IMO, we have to work with proffesionals.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

I don't think EK would want to do that. He stated that his love is coding, he must be burnt out already. Maybe an escrow manager might be more ideal.

i vote for this.

and the majority of fund shall be rewards to devs. 

[NutMasterTardd]

Any volunteer for keeping the PR donations?

IMO, we have to work with proffesionals.

Bob, what do you think if we vote for EK to be in charge of the funds ? He's trustworthy, he's been with this project from the beginning. He is not greedy . What do you guys think ?

I don't think EK would want to do that. He stated that his love is coding, he must be burnt out already. Maybe an escrow manager might be more ideal.

i vote for this.

and the majority of fund shall be rewards to devs.  

+1

Been a lurker since ICO, clearly the man is trustworthy and dedicated. It could be a great choice if he is willing?

[cybterpunk]

this project is promising, looking forward to the release.

hope this project will be released in 2 months.

[Bgjjj2016]

this project is promising, looking forward to the release.

hope this project will be released in 2 months.

something strange and funny about this post !

[lenyro]

Many people has waited for the launch for half year, you know the price will be very high if the XEL has a successful and smooth launch.

[Evil-Knievel]

Small update from my side. The last 5 days I have spent implementing the SN logic into the mining application itself and I think it's time to press the delete button and implement the SN logic into the core client itself.

Problems, that came up:
- Getting a stable and high available JSON RPC server running, I have one based on libevent but its highly experimental and well unter-tested
- With this approach we have additional overhead regarding the communication between the SN program and the core client in terms of signing transactions, verifying them, etc. This is one additional point of failure.
- Also, the SN would run on an extra port causing more overhead to SN operators since they have to open yet another port in their firewalls.

So, why reinvent the wheel when SN run the core client anyway and have all networking stuff on bord already:
I am right now doing the SN logic in the core client itself. Here, we have the entire networking part (incl. blacklisting) already running and well tested. All signing functions are already there and the only thing that we need is the uplink to the mining application for the code evaluation itself.

Good news: For massive testing, it's enough to have a pseudo SN, who does some very light checks on the work (code correctness, WCET, ...). This will be done today and if you like you can start right into the testnet this evening.


PS: Whoever likes to have a libevent based JSON-RPC server written in C for his own project, just tell me. You can have the SN stuff that was done in the last 5 days.

When we update the core client to do the real work checks on the SN side, this will not cause any soft/hardfork. The "SN only" have to update their clients themselves.

[Bgjjj2016]

Small update from my side. The last 5 days I have spent implementing the SN logic into the mining application itself and I think it's time to press the delete button and implement the SN logic into the core client itself.

Problems, that came up:
- Getting a stable and high available JSON RPC server running, I have one based on libevent but its highly experimental and well unter-tested
- With this approach we have additional overhead regarding the communication between the SN program and the core client in terms of signing transactions, verifying them, etc. This is one additional point of failure.
- Also, the SN would run on an extra port causing more overhead to SN operators since they have to open yet another port in their firewalls.

So, why reinvent the wheel when SN run the core client anyway and have all networking stuff on bord already:
I am right now doing the SN logic in the core client itself. Here, we have the entire networking part (incl. blacklisting) already running and well tested. All signing functions are already there and the only thing that we need is the uplink to the mining application for the code evaluation itself.

Good news: For massive testing, it's enough to have a pseudo SN, who does some very light checks on the work (code correctness, WCET, ...). This will be done today and if you like you can start right into the testnet this evening.


PS: Whoever likes to have a libevent based JSON-RPC server written in C for his own project, just tell me. You can have the SN stuff that was done in the last 5 days.

When we update the core client to do the real work checks on the SN side, this will not cause any soft/hardfork. The "SN only" have to update their clients themselves.

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

[Godson_Mansa]

you guys shill to damn much
lol
but still the project is interesting

where can i get info on the coinage/buy some.

[tomkat]

you guys shill to damn much
lol
but still the project is interesting

where can i get info on the coinage/buy some.

Not too much info out there, but you can find something here http://www.elastic-project.com.

There're 100M coins, and it's based on NXT so no inflation here.

If you want to buy before mainnet, then you could try with escrow - here are some offers
https://bitcointalk.org/index.php?topic=1589333.0, but you will need to wait anyway since there's no way for anyone to control their coins at the moment.

[lda1000]

@EK - thanks for the update, let us know when we can join testing.

Good decision to drop the separate SN process and incorporate it in to the main client.

[Selerius]

[...]

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

Hardware requirements for a SN are not that high.  I don't speak for EK, but there is practical certainty he has it totally covered.

[Bgjjj2016]

[...]

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

Hardware requirements for a SN are not that high.  I don't speak for EK, but there is practical certainty he has it totally covered.

Thank you for explaining. I heard " overhead".... I probably misunderstood.

[juras54]

this project is promising, looking forward to the release.

hope this project will be released in 2 months.

I've been waiting for a year, but then I like to test everything and test)

[clivemy]

[...]

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

Hardware requirements for a SN are not that high.  I don't speak for EK, but there is practical certainty he has it totally covered.

I've been wondering what the specs would be to run an SN, now core software & SN.

Can I ask what you think would be the specs for a system to run the software, approximately.

[Selerius]

[...]

Hi EK, always good to hear from you. Thanks for the updates.
Maybe I misunderstood, please forgive me in advance. Do we need any funding for any equipment you need to test the SN ?

Hardware requirements for a SN are not that high.  I don't speak for EK, but there is practical certainty he has it totally covered.

I've been wondering what the specs would be to run an SN, now core software & SN.

Can I ask what you think would be the specs for a system to run the software, approximately.

As far as I know, supernodes are supposed to be reliably online, maintain a large XEL deposit as a sign of relative trustworthiness, and accept running novel foreign code (an aspect which should be safe in the restricted language used but still such that some places would feel more comfortable just running a regular node instead).

Yet the actual hardware requirements are apparently not really super extreme.  At least back on January 24th, EK made a reference to work using 5 gigabytes of RAM memory (on top of ordinary use by the operating system and so on, of course).

Since 16GB and 32GB RAM desktops are not uncommon among recent models today, that wouldn't be much at all.  The supernode vs regular node hardware requirements difference may not be "super extreme" versus "ordinary" so much as "mildly high" versus "okay even if really mediocre and outdated."  Of course, the adjectives are my own, not EK's, not a quote.

I don't know if exactly the 5 GB example is still representative.

But my earlier comment was mainly just based on the following: I think EK is coding supernodes to run on what he already has now, as the only easy way to do development and testing.  He is not programming them in a manner which would require him to get much different hardware.  There would be no reason to do the latter, as he chooses the expected complexity and memory requirements of work packages, which were originally going to be scaled down to even relatively mediocre computers.

For a fully specific answer with exact numbers, we might need to wait for EK to announce it when he is done coding.  I am no real expert, just a bystander.  Yet I bet it will be that just about any 16GB RAM (or maybe even 8GB) computer with permanent internet access could do it, if willing to have a large portion of system resources consumed running the software.